FAQ#
一般情報
Linux* や Windows* で C++11 以降の C++ 標準機能を使用しているソースファイルを移行するにはどうすればいいですか?
sycl::malloc_device、sycl::malloc_host、および dpct::dpct_malloc で割り当てられるメモリー空間は初期化されていますか?
移行のトラブルシューティング
一般情報#
Linux* や Windows* で C++11 以降の C++ 標準機能を使用しているソースファイルを移行するにはどうすればいいですか? #
Linux* では、インテル® DPC++ 互換性ツールのパーサーは、デフォルトで C++98 と一部の C++11 機能をサポートします。インテル® DPC++ 互換性ツールでほかの C++11 以降の機能を有効にするには、--extra-arg="-std=<value>" オプションをコマンドラインに追加します。value に設定可能な値は以下のとおりです。
c++11c++14c++17
Windows* では、インテル® DPC++ 互換性ツールのパーサーは、デフォルトで C++14 をサポートします。インテル® DPC++ 互換性ツールで C++17 の機能を有効にするには、--extra-arg="-std=c++17" オプションをコマンドラインに追加します。
CMake プロジェクトを使用している場合、Windows* 上でファイルを移行するにはどうすればいいですか? #
Windows* 上の CMake プロジェクトでは、CMake を使用して Microsoft* Visual Studio* プロジェクト・ファイル (vcxproj) を生成できます。その後、以下のいずれかのオプションを選択します。
インテル® DPC++ 互換性ツールの
--vcxprojfileオプションを使用して、コマンドラインでソースファイルを移行します。インテル® DPC++ 互換性ツールの Microsoft* Visual Studio* プラグインを使用して、Microsoft* Visual Studio* でプロジェクト全体を移行します。
移行されたコードのフォーマットはどうなっていますか? #
インテル® DPC++ 互換性ツールは、移行したコードのフォーマットを制御するため--format-range と --format-style オプションを提供しています。
入力ソースコードが適切にフォーマットされている場合、インテル® DPC++ 互換性ツールはデフォルトのオプション設定である --format-range と --format-style を使用して結果コードをフォーマットします。
入力ソースコードが適切にフォーマットされていない場合 (例えば、タブとスペースの混在や異なるインデントが検出された場合)、以下のいずれかを行うことができます。
インテル® DPC++ 互換性ツールは、オリジナルコードのインデントサイズを検出して結果コード に適用します。
.clang-formatファイルでTabWidthとUseTabを設定してツールに指示できます。ただし、入力ソースコードが適切にフォーマットされていないと、移行したコード内のインデントが一致しない可能性があります。--format-range=allオプションを指定してインテル® DPC++ 互換性ツールを実行し、結果ファイル全体をフォーマットします。入力ソースコードと結果ソースコードの変化が激しく、コードの比較が困難な場合があります。入力ソースコードをフォーマットして、同じ
.clang-formatファイルでインテル® DPC++ 互換性ツールを使用して移行します。
コンパイル・データベースにプロジェクト内のすべてのファイルが含まれていないのはなぜですか? #
プロジェクトのビルドフォルダーで、intercept-build make [target] コマンドを使用してコンパイル・データベースを生成します。コンパイル・データベースの内容は、オプションの [target] パラメーターに依存します。デフォルトのビルドターゲットに対応するファイルリストを取得する必要がある場合は、[target] パラメーターを指定しません。
intercept-build を実行する前に、プロジェクトの ccache (コンパイラー・キャッシュ) を無効にしてください。ccache が有効の場合、ターゲット・オブジェクトがキャッシュ内にすでに存在すると、一部のコンパイル・コマンドがスキップされる可能性があるため、intercept-build で完全なコンパイル・データベースを生成できません。intercept-build を実行する前に、次のコマンドを使用して ccache を無効にします。
export CCACHE_DISABLE=1移行したモジュールファイルを新しいプロジェクトで使用するにはどうすればいいですか? #
.cu モジュールファイルは、オリジナル・プロジェクトの -ptx または -cubin オプションでコンパイルされ、cuModuleLoad() や cuModuleLoadData() で別の *.cu ファイルに動的にロードされます。
インテル® DPC++ 互換性ツールは、ほかの *.cu ファイルと同様に、モジュールファイルのコードを移行します。さらに、モジュールファイル内の _global_ 属性を持つ各関数ににラッパー関数を追加します。
移行したモジュールファイルをダイナミック・ライブラリーにコンパイルして、プラットフォーム向けの適切なダイナミック・ライブラリー API でロードします。以下に例を示します。
Linux* では、
dlopen()でダイナミック・ライブラリー (.so) をロードします。Windows* では、
LoadLibraryA()でダイナミック・ライブラリー (.dll) をロードします。
sycl::malloc_device、sycl::malloc_host、および dpct::dpct_malloc で割り当てられるメモリー空間は初期化されていますか? #
sycl::malloc_device、sycl::malloc_host、および dpct::dpct_malloc で割り当てられるメモリーは初期化されていません。新たに割り当てられるメモリーの初期値に明示的または暗黙的に依存しているプログラムは、実行時に失敗する可能性があります。このような失敗を回避するため、コードを調整してください。
例えば、以下のオリジナルコードについて考えてみます。
1// 元のコード
2
3int *device_mem = nullptr;device_mem = sycl::malloc_device<int>(size, dpct::get_default_queue());
4device_mem[0] += somevalue;新たに割り当てられたメモリーを使用する前に、0 に初期化するようにします。
1// 修正された SYCL コード
2
3int *device_mem = nullptr;device_mem = sycl::malloc_device<int>(size, dpct::get_default_queue());
4dpct::get_default_queue().memset(0, size).wait();
5device_mem[0] += somevalue;CUB* ライブラリー実装ソースコードを含む CUDA* ソースコードを移行するにはどうすればいいですか? #
CUB* ライブラリー実装コードを直接移行すると、期待する結果が得られないことがあります。代わりに、--in-root-exclude=<path to CUB library source code> を移行コマンドに追加して、CUB* ライブラリー実装ソースコードを移行から除外します。
移行のトラブルシューティング #
dpct -in-root=srcdir -out-root=dstdir *.cu でファイルを移行すると、「error: unknown type name (エラー: 不明なタイプ名です)」などのエラーが発生しますが、どうすれば解決できますか? #
この問題は、*.cu リストに含まれるファイルのうち、ヘッダーファイル (#include 文でインクルードされる) として使用され、スタンドアロン・ファイルとして解析されることを想定していないファイルが原因の可能性があります。ファイルがほかのファイルの定義/宣言に依存しているためファイルを解析できない場合、インテル® DPC++ 互換性ツールはエラーを報告します。次のいずれかの方法でコンテンツを移行します。
インテル® DPC++ 互換性ツールに移行するファイルを決定させます。
compile_commands.json: "dpct -p=compile_commands.json --in-root=srcdir --out-root=dstdir"手動で特定のファイルを渡します。ただし、ほかのファイルにインクルードされており、オリジナルのアプリケーションでスタンドアロンのファイルとしてコンパイルされることを想定していないファイルは渡せません。入力ファイルにインクルードされており、
in-rootフォルダー以下にあるヘッダーファイルは自動的に移行されます。
dpct --in-root= srcdir --out-root=dstdir sample.cu
Windows* でコードを移行する際に、「no member named 'max' in namespace 'std' ('std' 名前空間に 'max' という名前のメンバーはありません)」や「no member named 'min' in namespace 'std' ('std' 名前空間に 'min' という名前のメンバーはありません)」などの解析エラーが発生した場合、どのように修正すればよいですか? #
以下のいずれかの方法でエラーを解決してください。
std::minとstd::maxを使用する前に、#include <algorithm>をソースファイルに追加します。WinDef.hをインクルードする前に、#define NOMINMAXを追加して NOMINMAX マクロを定義します。
Linux* 上で移行されたコードを Windows* 上でコンパイルする際に「error: dlopen not declared (エラー: dlopen は宣言されていません)」などのコンパイルエラーが発生した場合、どのように修正すればよいですか? #
インテル® DPC++ 互換性ツールはソースコードを生成する際に、ツールが動作している OS に固有の動的ロード API を使用します。
例えば、Linux* では dlopen、dlclose、dlsym が使用され、Windows* では LoadLibraryA、FreeLibrary、GetProcAddress が使用されます。
別の OS で移行されたコードをコンパイルする場合は、インテル® DPC++ 互換性ツールを使用してターゲット OS でプロジェクトを再度移行するか、手動でコードを修正します。
なぜ atomic* API は移行されないのですか? #
インテル® DPC++ 互換性ツールは、atomic* API をユーザー定義の API であると仮定すると移行しません。
これは、以下の場合に発生する可能性があります。
CUDA* インクルード・パスが
--cuda-include-pathと-I*の両方で指定されているが、パスが異なる場合。CUDA* インクルード・パスが
-I*で指定されているが、デフォルトの CUDA* インストール・パスにほかの CUDA* インクルード・ファイルが存在する場合。
atomic* API が確実に移行されるようにするには、dpct 移行コマンドで CUDA* インクルード・パスを指定する際に -I* をを使用しないでください。代わりに、--cuda-include-path で CUDA* インクルード・パスを指定してください。
「error: restrict requires a pointer or reference (エラー: restrict には参照へのポインターが必要です)」で移行に失敗しました、何が原因ですか? #
C++ 標準では restrict 修飾子をサポートしておらず、C 標準ではオブジェクト型へのポインターでのみ restrict 修飾子をサポートしています。
これらの言語標準に基づいて、インテル® DPC++ 互換性ツールは解析エラーを出力します。
ソースコードの調整が必要な場合があります。
別のアプリケーションで複数回ロードされるライブラリー・プロジェクトで、dpct::dev_mgr と dpct:mem_mgr のランタイム動作が正しくない場合、どのように解決したらよいですか? #
dpct::dev_mgr と dpct::mem_mgr は、インテル® DPC++ 互換性ツールのヘルパー関数のシングルトン・クラスです。ヘルパー関数のヘッダーを使用して実行形式のプロジェクトのビルドする場合、dpct::dev_mgr と dpct::mem_mgr はどちらも、実行形式では 1 つのインスタンスになります。しかし、ヘルパー関数のヘッダーを使用して、アプリケーション内で dlopen() (Windows* では LoadLibraryA()) を使って複数回ロードされるライブラリー・プロジェクトをビルドする場合、dpct::dev_mgr と dpct::mem_mgr の 3 つ以上のインスタンスが作成され、正しくないランタイム動作になります。
例えば、libA.cpp と libB.cpp の両方のファイルがインテル® DPC++ 互換性ツールのヘルパー関数のヘッダー dpct.hpp をインクルードすると、それぞれダイナミック・ライブラリー libA.so と libB.so にビルドされます。アプリケーション main.cpp が dlopen() を使ってこれらのライブラリーをインポートすると、アプリケーションのランタイムで dpct::dev_mgr と dpct::mem_mgr の 2 つのインスタンスが作成されます。
この問題を解決するには、インテル® DPC++ 互換性ツールのヘルパー関数で dpct::dev_mgr と dpct::mem_mgr の実装と宣言を分離します。
新しい C++ ファイル
dpct_helper.cppを作成します。class dev_mgrのinstance()の実装をdpct/device.hppからdpct_helper.cppへ移動します。例えば、以下はオリジナルの
dpct/device.hppです。1 class dev_mgr { 2 public: 3 static dev_mgr &instance() { // 実装と dev_mgr::instance の宣言 4 static dev_mgr d_m; 5 return d_m; 6 } 7 ... 8 }
これを次のように変更します。
1 class dev_mgr { 2 public: 3 static dev_mgr &instance();// dev_mgr::instance の宣言 4 ... 5 }
そして、新しい
dpct_helper.cppにdev_mgr::instance()の実装を含めます。1#include <dpct/device.hpp> 2dpct::dev_mgr &dev_mgr::instance(){ // dev_mgr::instance の実装 3 static dev_mgr d_m; 4 return d_m; 5}
ステップ 2 と同様に、
class mem_mgrのinstance()実装をdpct/memory.hppからdpct_helper.cppに移動します。dpct_helper.cppをダイナミック・ライブラリーlibdpct_helperとしてビルドします。Linux*:
dpcpp -g -shared -o libdpct_helper.so -fPIC ./dpct_helper.cpp
Windows*:
cl.exe /LD dpct_helper.cpp
libdpct_helperライブラリーを環境変数に追加します。Linux*:
libdpct_helper.soの場所をLD_LIBRARY_PATHに追加します。Windows*:
libdpct_helper.dllの場所をPATHに追加します。
ライブラリーやアプリケーションをビルドする際に
libdpct_helperを動的にリンクします。
上記のステップを実行すると、すべてのライブラリーとアプリケーションは、インテル® DPC++ 互換性ツールのヘルパー関数の dpct::dev_mgr デバイス・マネージャーと dpct::mem_mgr メモリー・マネージャーの同じインスタンスを共有するようになります。
移行したコードをインテル® oneAPI DPC++/C++ コンパイラーでコンパイルすると「warning: shift count >= width of type (警告: シフトカウントが型の長さよりも大きい)」になります。何が原因ですか? #
シフトカウントが型の長さよりも大きいシフト操作は、インテル® oneAPI DPC++/C++ コンパイラー (英語) では未定義の動作であり、デバイスによって異なる動作になる可能性があります。コードを調整して、このようなシフト操作は回避してください。
例えば、以下は移行された SYCL* コードです。
1// 移行された SYCL* コード 2 3void foo() { 4 ... 5 unsigned int bit = index[tid] % 32; 6 unsigned int val = in[tid] << 32 - bit; 7 ... 8}シフトカウントが型の長さよりも大きくならないように、このコードを調整します。
1// 修正された SYCL* コード 2 3void foo() { 4 ... 5 unsigned int bit = index[tid] % 32; 6 unsigned int val; 7 if(32 - bit == 32) 8 val = 0; 9 else 10 val = in[tid] << 32 - bit; 11 ... 12}コードの移行時に発生する解決できないインクルードエラーにはどのように対処できますか? #
--extra-arg=-v オプションを使用すると、インテル® DPC++ 互換性ツールは詳しい情報を出力します。これには、ツールの検索パスに関連する情報も含まれます。
次のいずれかの方法で、インクルード検索の追加パスを指定します。
移行コマンドで
--extra-arg="-I<extra include path>"オプションを使用して、移行中にインクルード検索にツールが使用する追加のパスを指定します。コンパイル・データベースを使用する場合、ソースファイルのデータベース内のコンパイルコマンドに
-I<extra include path>オプションを追加して、インクルード・パスを指定します。