1

大規模なプロジェクトの一環として、奇妙に一貫したバグに出くわしました。これは理解できませんが、典型的な「ブラック ボックス」バグです。で実行するとcuda-gdb python -m pycuda.debug prog.py -args、正常に実行されますが、遅くなります。pycuda.debug をドロップすると壊れます。一貫して、複数カーネル実行のまったく同じ時点で。

説明する; 私は（現在3つの）カーネルを持っており、異なるグリッドとブロックの配置で使用され、より大きな最適化問題の「スライス」を解決しています。これらは厳密に言えば、機能するかどうかのどちらかです。関数自体には「ここにいくつかのデータがあります」としか言われず、データの内容以外には、入力データが分割されているかどうかにかかわらず、反復回数などの何もわからないためです。ではなく、この時点までは完璧に機能します。

基本的に、デバッグ シンボルを GDB に公開する pycuda.debug なしでは何が起こっているのかわかりませんが、pycuda.debug で問題を確認することもできません。

pycuda は実際に何をするので、カーネル コードで何を探すべきかがわかりますか?

4

1 に答える 1

1

ほとんど何もありません。ほとんどの場合、pycuda.driver モジュールにコンパイラ フラグを設定して、CUDA コードが必要なデバッグ シンボルでコンパイルされ、CUDA-gdb が必要とする方法でアセンブルされるようにします。残りは、すべてが機能するように、pycuda ライブラリを適切にカプセル化する小さなラッパーです。全体で約 20 行の python です。必要に応じて、ソース配布物でコードを確認できます。

ここで重要なことは、デバッガーで実行されるコードは、レジスターと共有メモリからローカル メモリにすべてをスピルし、ドライバーがローカル プログラムの状態を読み取れるようにすることです。そのため、デバッガー用にビルドすると実行され、通常にビルドすると失敗するコードがある場合は、通常、セグメンテーション違反に相当する GPU を引き起こしている共有メモリ バッファー オーバーフローまたはポインター エラーがあることを意味します。

于 2011-04-25T05:14:32.053 に答える