2017-02-18 82 views
1

例如,我有三个任务A,B和C.其中B和C取决于A.并且有足够的CU可以同时运行B和C.然后我排队A和C在队列0上,B在队列1上排队。在A完成之后和B开始之前有一个巨大的延迟,这使得整个工作比仅使用一个队列花费的时间更长。AMD OpenCL异步执行效率

这是正常的吗?或者我可以做错什么?

我会写一个示例代码,如果需要,原始代码是严重封装。但实际上,我只是在排入A并将它传递给B的排队时创建一个事件,并且这两个队列在顺序队列中都是正常的。似乎没有什么特别的。

+0

我正在使用类似的并行队列,并观察事件驱动的步骤与HD7870和R7-240之间的延迟。然后,我将队列更改为:A + B + C在同一队列中,但是每当有10倍(A + B + C)时,都会重复,因此10队列会生成并快速运行而不会出现任何结尾。处理最佳操作顺序的驱动程序,正如我从codeXL时间图中看到的 –

+0

@huseyintugrulbuyukisik猜测也许这只是正常...有时我只是觉得AMD在开玩笑我们... – BlueWanderer

回答

0

我找不到任何有关延迟的信息,但打电话给正常的东西,我们需要统计上得到的延迟基地为所有平台,这里是我的:

HD7870和R7-240显示相同的行为。 Windows 10.双通道RAM。 OpenCl 1.2(64位版本)。 CodeXL分析。所有按序排队。一些老司机在深红之前。

  • eventless单个队列无阻塞命令:几微秒到200微秒波动,但平均要低像50微秒,这取决于驱动器,对于一些内核它去500微秒,因为太多的参数的可能和类似的准备。
  • 事件源=单个队列-A,事件目标=队列-B: 100-150微秒到半毫秒(似乎常数)
  • 事件源= N-1的队列列表中,事件目标= queue- N:不是队列的所有等待时间的总和,但隐藏的某种延迟是有的,所以它不超过2毫秒(有时峰值很少到3-5毫秒很少)
  • 事件源=队列,由主机的clWaitForEvents等待:大约一毫秒
  • 事件源=队列,正在等待clGetEventI来自主机的nfo在while循环中:接近半毫秒,有时甚至更少
  • clFinish for single queue:这样每个队列的延迟最少,至少为1ms。
  • 用户事件:在codeXL中产生错误,所以我无法查询它们的性能,但它是一个较旧的驱动程序和较旧的codeXL版本。

存在后台进程:avira,谷歌浏览器,..这些进程足够先进,可以使用GPU达到其目的,并且可能会妨碍内核执行。

我对这些问题的解决方案是通过使用许多独立队列来隐藏事件延迟并像魅力一样工作。 R7-240以16-排队运行。它只有2个ACE单位,所以具有4-8个的新牌可以处理更多的队列。

我没有想到的是:N队列正在等待完成其他队列中的事件列表性能。也许树状等待结构对于许多队列来说可能会更好,如果它们太滞后的话。

+0

在我的斐济设备上,同步的延迟仅为1微秒执行,这使得异步执行的延迟就像一场噩梦。我想知道是否有正确的方式来执行异步执行,这样就没有这种延迟。 “事件不应该只是依赖于GPU方面?”我想。而AMD说,这是他们的GPU擅长的,谁知道... – BlueWanderer

+0

1我们相比我的显卡好。有超过1个Ace单位因此复制所有队列应该隐藏它 –

+0

猜测CU必须在任务之间留下“空闲”1us(更精确地说,约1.5us),使用多个队列似乎不会隐藏它。无论如何,因为每个内核需要大约50us才能运行,如果我扩大任务以填充CU的话,则更多。 – BlueWanderer