OpenCLメモ (その4) - 転送(コピー)の排除 (USE_HOST_PTR)

CPUメモリとOpenCLバッファ(GPUメモリ)は通常別のアドレス空間であり、転送が必要である。NVIDIA等のdGPUなら、物理的にも別のメモリであるから、転送が必要なのは、まあ、当たり前だろう。

しかし、この転送というのはくせ者で、たいてい結構重い。計算より転送が重いなんていうのは、ありがちな話だ。例えば、以下の例でもピンクの部分が実際の計算だが、その前後の緑/青色の転送のほうが時間がかかってしまっている。



IntelのGPUでOpenCLを使用する場合、そのメモリはCPUと物理的には同一メモリ上にある。そのため、OpenCL 1.2以降で使用可能なUSE_HOSRT_PTRという仕組みを使って、転送を不要にすることができる。これをIntelではZeroCopyと呼んでいる。

参考資料
iSUS - OpenCL* 1.2 の活用: インテル® プロセッサー・グラフィックスでバッファーコピーを最小限に抑えてパフォーマンスを向上する方法
Intel Developer Zone - Getting the Most from OpenCL™ 1.2: How to Increase Performance by Minimizing Buffer Copies on Intel® Processor Graphics

今回はこれを試してみる。

USE_HOST_PTRを使用する場合の手順はこんな感じ。

まず、CPU側のメモリ確保で2つの点で注意する。
・4096バイトでアラインされている
・バッファのサイズは64バイトの倍数

これは、_aligned_malloc()を使ってアライン済みアドレスを取得することで解決できる。


cl_uint optimizedSize
= ceil_int(sizeof(cl_int) * arrayWidth * arrayHeight, 64);
cl_int* inputA = (cl_int*)_aligned_malloc(optimizedSize, 4096);
cl_int* inputB = (cl_int*)_aligned_malloc(optimizedSize, 4096);
cl_int* outputC = (cl_int*)_aligned_malloc(optimizedSize, 4096);


そして、このポインタを使って、OpenCLバッファを作成する。


int CreateBufferArguments(
ocl_args_d_t *ocl,
cl_int* inputA, //CPU側の入力配列へのポインタ
cl_int* inputB, //CPU側の入力配列へのポインタ
cl_int* outputC, //CPU側の出力配列へのポインタ
cl_uint width, cl_uint height //配列のサイズ
) {
cl_int err = CL_SUCCESS;
cl_uint optimizedSize
= ceil_int(sizeof(cl_int) * arrayWidth * arrayHeight, 64);
ocl->srcA = clCreateBuffer(ocl->context,
//CL_MEM_USE_HOST_PTRを追加
CL_MEM_READ_ONLY | CL_MEM_USE_HOST_PTR,
optimizedSize, //配列のサイズ
inputA, //対応するCPUメモリへのポインタ
&err); //エラー情報を受け取る

ocl->srcB = clCreateBuffer(ocl->context,
//CL_MEM_USE_HOST_PTRを追加
CL_MEM_READ_ONLY | CL_MEM_USE_HOST_PTR,
optimizedSize, //配列のサイズ
inputB, //対応するCPUメモリへのポインタ
&err); //エラー情報を受け取る

ocl->dstMem = clCreateBuffer(ocl->context,
//CL_MEM_USE_HOST_PTRを追加
CL_MEM_WRITE_ONLY | CL_MEM_USE_HOST_PTR,
optimizedSize, //配列のサイズ
outputC, //対応するCPUメモリへのポインタ
&err); //エラー情報を受け取る

return err;
}


このように作成した領域について、ホスト(CPU)側から操作する場合には、clEnqueueMapBuffer()を呼び出し、操作し終わったら、clEnqueueUnmapMemObject()を呼び出す必要がある。(これでCPU-GPU間の同期がとられる)


//対応するホスト側のポインタを取得する
cl_int *ptrMappedA = (cl_int *)clEnqueueMapBuffer(
ocl.commandQueue, //投入キュー
ocl.srcA, //対象のOpenCLバッファ
CL_FALSE, //終了までブロックするか -> しない
CL_MAP_WRITE, //CPUが書き込むためにMapする
//(読み込みならCL_MAP_READ)
//(両方ならCL_MAP_READ | CL_MAP_WRITE)
0, //オフセット
sizeof(cl_uint) * arrayWidth * arrayHeight, //マップするサイズ
0, //この関数が待機すべきeventの数
NULL, //この関数が待機すべき関数のリストへのポインタ
NULL, //この関数の返すevent
&err);

//終了を待機
err = clFinish(ocl.commandQueue);

//ホスト(CPU)から操作
//(...略...)

err = clEnqueueUnmapMemObject(
ocl.commandQueue, //投入キュー
ocl.srcA, //対象のOpenCLバッファ
ptrMappedA, //取得したホスト側のポインタ
0, //この関数が待機すべきeventの数
NULL, //この関数が待機すべき関数のリストへのポインタ
NULL); //この関数の返すevent

//終了を待機
err = clFinish(ocl.commandQueue);

//デバイス(GPU) kernelを実行
//(...略...)


Map / Unmapが少し面倒であるが、このようにすることで転送が完全に省略される。clEnqueueUnmapMemObject()での転送時間が1usととても短くなり、事実上転送は行われていないことがわかる。




これに対し、アライメントが取れていないアドレスをclCreateBufferに渡すと、clEnqueueUnmapMemObject()で転送が起こってしまい、1.3ms前後かかってしまっている。





ZeroCopyを使用するには、今回のように、自分でCPU側のメモリを_aligned_malloc()で確保し、そのアドレスからUSE_HOST_PTR付きのclCreateBuffer()でOpenCLバッファを作る方法のほかに、ALLOC_HOST_PTR付きのclCreateBuffer()でOpenCLバッファを作る方法があり、この場合はOpenCL側でメモリを確保してくれる。


ocl->srcA = clCreateBuffer(ocl->context,
//CL_MEM_ALLOC_HOST_PTRを追加
CL_MEM_READ_ONLY | CL_MEM_ALLOC_HOST_PTR,
optimizedSize, //配列のサイズ
inputA, //OpenCL側で確保してくれるので不要
&err); //エラー情報を受け取る


こちらのほうが使いやすい場合もあるかもしれない。



今回のちゃんと動くコードはこちら



続き>>



OpenCLメモリスト
OpenCLメモ (その1) - かんたんな計算
OpenCLメモ (その2) - Intel GPUの構造
OpenCLメモ (その3) - work sizeの調整
OpenCLメモ (その4) - 転送(コピー)の排除 (USE_HOST_PTR) (いまここ)
OpenCLメモ (その5) - 転送(コピー)の排除 (SVM : OpenCL 2.0)
OpenCLメモ (その6) - imageの使用
OpenCLメモ (その7) [終] - reductionとshared local memory(SLM)の使用


コメントの投稿

非公開コメント

プロフィール

rigaya

Author:rigaya
アニメとか見たり、エンコードしたり。
連絡先: [email protected]
github twitter

最新記事
最新コメント
カテゴリ
月別アーカイブ
カウンター
検索フォーム
いろいろ
公開中のAviutlプラグインとかのダウンロード

○Aviutl 出力プラグイン
x264guiEx 3.xx
- x264を使用したH264出力
- x264guiExの導入紹介動画>
- x264guiExの導入
- x264guiExのエラーと対処方法>
- x264.exeはこちら&gt

x265guiEx
- x265を使用したH.265/HEVC出力
- x265guiExの導入>
- x265.exeはこちら&gt

QSVEnc + QSVEncC
- QuickSyncVideoによるHWエンコード
- QSVEnc 導入/使用方法&gt
- QSVEncCオプション一覧&gt

NVEnc + NVEncC
- NVIDIAのNVEncによるHWエンコード
- NVEnc 導入/使用方法&gt
- NVEncCオプション一覧&gt

VCEEnc + VCEEncC
- AMDのVCE/VCNによるHWエンコード
- VCEEnc 導入/使用方法&gt
- VCEEncCオプション一覧&gt

svtAV1guiEx
- SVT-AV1によるAV1出力
- svtAV1guiExの導入>
- SVT-AV1単体はこちら&gt

VVenCguiEx
- VVenCによるVVC出力
- VVenCguiExの導入>

ffmpegOut
- ffmpegを使用した出力
- ffmpegOutの導入>


○Aviutl フィルタプラグイン
自動フィールドシフト
- SSE2~AVX512による高速化版
- オリジナル: aji様

clcufilters 
- OpenCL/CUDAのGPUフィルタ集
- 対応フィルタの一覧等はこちら

エッジレベル調整MT
- エッジレベル調整の並列化/高速化
- SSE2~AVX512対応
- オリジナル: まじぽか太郎様

バンディング低減MT
- SSE2~AVX512による高速化版
- オリジナル: まじぽか太郎様

PMD_MT
- SSE2~AVX512による高速化版
- オリジナル: スレ48≫989氏

透過性ロゴ (ミラー)
- SSE2~FMA3によるSIMD版
- オリジナル: MakKi氏

AviutlColor
- BT.2020nc向け色変換プラグイン
- BT.709/BT.601向けも同梱

○その他
Amatsukaze改造版
- AmatsukazeのAV1対応版

tsreplace
- tsの映像のみを置き換えて圧縮

rkmppenc
- Rockchip系SoCのhwエンコーダ

fawutil
- FAW(FakeAACWave)⇔aac変換
- 二重音声の取り扱いにも対応

x264afs (ミラー)
- x264のafs対応版

aui_indexer (使い方>)
- lsmashinput.aui/m2v.auiの
 インデックス事前・一括生成

auc_export (ミラー使い方>)
- Aviutl Controlの
 エクスポートプラグイン版
 エクスポートをコマンドから

aup_reseter
- aupプロジェクトファイルの
 終了フラグを一括リセット

CheckBitrate (使い方)
- ビットレート分布の分析(HEVC対応)

チャプター変換 (使い方>)
- nero/appleチャプター形式変換

エッジレベル調整 (avisynth)
- Avisynth用エッジレベル調整

メモリ・キャッシュ速度測定
- スレッド数を変えて測定
- これまでの測定結果はこちら

○ビルドしたものとか
L-SMASH (ミラー)
x264 (ミラー)
x265 (ミラー)
SVT-AV1 (ミラー)

○その他
サンプル動画
その他

○読みもの (ミラー)
Aviutl/x264guiExの色変換
動画関連ダウンロードリンク集
簡易インストーラの概要

○更新停止・公開終了
改造版x264gui
x264guiEx 0.xx
RSSリンクの表示
リンク
QRコード
QR