問題タブ [ptx]

PTX コードを変更して直接コンパイルする必要があります。その理由は、いくつかの特定の命令を次々に配置したいためであり、ターゲットの PTX コードを生成する cuda コードを記述するのは難しいため、ptx コードを直接変更する必要があります。問題は、(fatbin と cubin) にコンパイルできることですが、それら (.fatbin と .cubin) を "Xo" ファイルにコンパイルする方法がわかりません。

CUDA コンパイラには、32 ビットまたは 64 ビットの PTX を生成するためのオプションがあります。これらの違いは何ですか？x86 の場合と同様に、NVidia GPU には実際に 32 ビットと 64 ビットの ISA がありますか? それとも、ホスト コードのみに関連していますか?

PTX ファイルに含まれる PTX 関数を外部デバイス関数として使用して、その関数を呼び出す別の .cu ファイルにリンクできますか?

これは CUDA からの別の質問です。関数自体が .cu ファイルに含まれていないカーネルを一緒にリンクしますが、何らかの方法でリンクする PTX 関数があります。

LLVM の NVPTX バックエンドによって生成された PTX アセンブリを読み込むときに、あいまいな例外が発生します。(ManagedCuda から PTX を読み込んでいます - http://managedcuda.codeplex.com/ )

モジュールの LLVM IR は次のとおりです (ツールによって生成されるため、少し奇妙です)。

これが結果の PTX です

PTX の読み方がわかりませんが、問題はstructtest 関数定義の.b0ビットに関係しているように感じます。.param .b0 structtest_param_0

構造体以外の値 (整数やポインターなど) を渡すことは正常に機能し、.b0. 関数のビットは、正気のようなものを読み取るか.b32、.b64そうするときに読み取ります。

トリプルを nvptx-nvidia-cuda (32 ビット) に変更しても何も起こらないだけでなく、http://llvm.org/docs/NVPTXUsage.html で提案されているデータ レイアウトを含めたり除外したりすることもできません。

これは NVPTX バックエンドのバグですか、それとも何か間違っていますか?

アップデート：

私はこれを見ています - http://llvm.org/docs/doxygen/html/NVPTXAsmPrinter_8cpp_source.html - タイプが line に落ちているように見え01568、明らかにプリミティブタイプではなく、Ty->getPrimitiveSizeInBits()ゼロを返します。（少なくとも、私の推測です）

構造体かどうかを確認し、アドレスを取得し、引数を作成し、byval後で構造体を逆参照するための特別なケースを追加する必要がありますか? それはハッキーな解決策のように思えますが、他に修正する方法がわかりません。

私はcudaコードを開発しています。しかし、PTX または SPIR バックエンドである新しいデバイス言語が発表されました。そして、彼らが開発しているアプリケーションに出くわすことができます。少なくとも、ptx 言語は製品レベルで何かを開発するのに十分であると言えます。

ご存じのとおり、PTX は実際のデバイス コードではありません。NVidiaの単なる中間言語です。しかし、私の質問は、CUDA の代わりに PTX を開発するとどうなるかということです。ptx を使用すると、自然に最適化されたコードを開発できますか? それは理にかなっていますか？

一方、なぜ/何が PTX 言語の動機ですか?

前もって感謝します

次の行を llvm コードに追加したい ( ptx バックエンドのドキュメントで指定されているように):

ただし、次のエラーが表示されます。

私は何を間違っていますか？

私のプロジェクトでは、いくつかの関数の PTX 命令を 2 つの異なる方法で生成しています。最初の方法は、CUDA C を使用して関数を実装し、nvcc を使用してそれらをコンパイルします nvcc -ptx <file>.cu -o <file>.ptx。もう 1 つの方法は、別の言語でコードを記述し、これから LLVM IR を生成し、NVPTX バックエンドを使用して ptx にコンパイルします。ここで遭遇する問題は、2 番目の状況では一部の関数のパフォーマンスが低下することです。他の関数は、多かれ少なかれ同等のパフォーマンスをもたらします。

ここで、一部の関数のパフォーマンスにこのような違いがある理由 (および他の関数には違いがない理由) を知りたいのですが、nsight を使用したプロファイリングではまだ良いアイデアが得られませんでした。

私が見つけた唯一の違いは、レジスタの使用法です。結果の ptx コードでは、次のことがわかります。

nvcc を使用してコンパイル

nvptx を使用してコンパイル

私が理解している限りでは、これは使用されている仮想レジスタの数と種類を示していますが、はっきりとわかるように、これは 2 番目のケースでは正しくありません。nsight でプロファイリングしたところ、実際に使用されたレジスタ/スレッドの数は、最初のケースで 8 個、2 番目のケースで 31 個であることがわかりました。もちろん、これは 2 番目のケースのコードが遅い理由を示している可能性がありますが、問題は、NVPTX を使用して LLVM IR から ptx にコンパイルされたすべての関数にこの問題があることです。一部の関数は最初のケースとほぼ同じパフォーマンスをもたらしますが、それらはすべて 396 個の使用済み仮想レジスターを持ち、nsight はそれらすべてに対して 31 個の使用済みレジスター/スレッドを報告しています。

これは速度低下の問題ですか? そして、それがすべての機能に影響しないのはなぜですか? そうでない場合、速度低下の原因は何ですか? 私が見るべき方向について何かヒントを教えてもらえますか？

ありがとう！

(使用しているLLVMのバージョンは3.3です)

編集:私が気づいたもう1つの違いは、失速の理由です:

NVCC:

NVPTX:

どうやら、「その他」の理由で相対的に増加しているようです。おそらくこれで問題が説明できるでしょうか？

編集:ptxソースコードを追加

ここに示す関数は、データをグローバル メモリから共有メモリにコピーします。次に、各スレッドは自身の要素と前の要素を配列の最後の要素と比較します。比較結果が正の場合、インデックスは出力配列に書き込まれます。

1) NVPTX を使用して PTX にコンパイルされた LLVM IR

2) nvcc を使用して PTX にコンパイルされた CUDA C

GTX760、CUDA v5.0 を搭載した Win7 x64 マシンで VS2010 を使用して OpenCV 2.4.8 の GPU モジュールをコンパイルしようとすると、各オブジェクト ビルド ルーチンの後に次のエラーが表示されます。

nvcc : 致命的なエラー: 複数の GPU コード インスタンスをコンパイルする場合、オプション '--cubin (-cubin)' は許可されません

これは何を意味するのでしょうか？ビルドする前に CMake のパラメーターを変更する必要がありますか?

サブスペース投影にgemmを使用できるように、CUBLASをビルドしてアプリケーションで認識させようとしているだけです。