最近、2 種類のカーネル ランタイム測定を比較しましたが、紛らわしい結果がいくつか見られます。
GPU と Ubuntu Linux が統合された AMD Bobcat CPU (E-350) を使用しています (CL_PLATFORM_VERSIONはOpenCL 1.2 AMD-APP (923.1))。
基本的な gettimeofday のアイデアは次のようになります。
clFinish(...) // that all tasks are finished on the command queue
gettimeofday(&starttime,0x0)
clEnqueueNDRangeKernel(...)
clFlush(...)
clWaitForEvents(...)
gettimeofday(&endtime,0x0)
これは、カーネルが約 5466 ミリ秒を必要とすることを示しています。
/ / /clGetEventProfilingInfoで行った2回目の測定。QUEUEDSUBMITSTARTEND
4 つの時間値を使用して、さまざまな状態で費やした時間を計算できます。
- キューに入れられた時間: 0.06 ミリ秒、
- 送信に費やした時間: 2733 ミリ秒、
- 実行に費やした時間: 2731 ミリ秒 (実際の実行時間)。
合計すると 5466 ミリ秒になることがわかりますが、半分の時間送信済み状態のままなのはなぜですか?
そして、面白いことは次のとおりです。
サブミットされた状態は、異なるカーネルまたは異なるワークロードであっても、常に実際の実行時間の半分です (したがって、一定のセットアップ時間にはなりません)。
CPU の場合、送信された状態で費やされた時間は 0 であり、実行時間は gettimeofday の結果と同じです。
CPU と GPU を使用する Windows を搭載した Intel Ivy Bridge でカーネルをテストしましたが、その影響は見られませんでした。
誰も手がかりを持っていますか？
GPU がカーネルを 2 回実行する (gettimeofday が実際の実行時間の 2 倍になる) か、関数 clGetEventProfilingInfo が AMD GPU に対して正しく機能していない可能性があります。