OpenCL的事件歧義

參照clGetEventProfilingInfo文檔，cl_event源於clEnqueueNDRangeKernel可以是：OpenCL的事件歧義

CL_PROFILING_COMMAND_QUEUED

當由事件標識的命令由排隊在命令隊列主人。

CL_PROFILING_COMMAND_SUBMIT

當已經排隊由事件標識的命令是由主機提交與commandqueue相關聯的設備。

CL_PROFILING_COMMAND_START

當由事件標識開始執行設備上的命令。

CL_PROFILING_COMMAND_END

當由事件標識的命令已經完成執行設備上。

假設可視化整仁分析：

COMMAND_QUEUED -> COMMAND_SUBMIT -> COMMAND_START -> COMMAND_END

&相應的時間表：

Queueing -> Submitting -> Executing

其中：

排隊= COMMAND_SUBMIT - COMMAND_QUEUED
提交= COMMAND_START - COMMAND_SUBMIT
執行= COMMAND_END - COMMAND_START

問題：
是我以前的公式真的嗎？如果是這樣，什麼的排隊和提交之間的真正區別？換句話說，如果我想將整個過程劃分爲COMMUNICATION（卸載）時間和COMPUTATION（執行）時間，那麼什麼是將是它們的等式？

來源

2016-10-07 Ahmed Ghoneim

你的解釋看起來相當真實。 QUEUED是當你調用OpenCL API時（比如clEnqueueNDRangeKernel）。 SUBMIT是運行時將工作交給設備的時間。 START是開始執行時，END是執行完成時。這四次之間有三種狀態。第一個狀態在主機上空閒。第二個狀態在設備上空閒。第三個狀態在設備上執行。如果您希望將前兩者合併爲「溝通」，則將它們加在一起（或使用COMMAND_START - COMMAND_QUEUED）。

來源

2016-10-08 00:43:29 Dithermaster

當在CPU上運行時，QUEUED = 0但是SUBMIT不是！爲什麼？ –

不知道爲什麼。聽起來像是實施中的一個錯誤。 – Dithermaster

我懷疑因爲gpu上的數字不同，提交需要比排隊更多的時間！什麼實現，這些讀數來自實際執行分析！ –

我以前的方程是真的？

是的。

如果是這樣，排隊和提交的真正區別是什麼？換句話說，如果我想把整個過程分成通信（卸載）時間和計算（執行）時間，它們的方程是什麼？

隊列：

時間花費在等待其他任務，以啓動當前一個結束。換句話說，等待所有依賴事件的CL_COMPLETE狀態，或者在當前排隊隊列中有空閒資源。
注意：排隊等待空閒設備時，CPU將有0個隊列時間，因爲它們是同步的。儘管GPU總是會有一些小的排隊時間（由於異步行爲）。這就是儘可能多地向GPU設備傳輸數據的原因。

提交：

花費的時間準備當前的任務（編譯LLVM，移動緩衝區，準備設備核等），要小，但不爲0

如果您正在查找公式，則只有「提交」和「執行」對於計算當前任務開銷是有效的。忽略排隊因爲它不依賴於你的任務：

Active% = Executing/(Executing+Submitting) 
Overhead% = Submitting/(Executing+Submitting)

來源

2016-10-10 13:04:19 DarkZeros

OpenCL的事件歧義

回答

相關問題