0

GTX550ti グラフィック カードで Nvidia の OpenCL 開発ソフトウェアを使用していますが、奇妙な問題が発生します。(私は OpenCL の新入生です)。

私のカーネルコードは次のようなものです:

__kernel void kernel_name(...)
{
size_t d = get_local_id(0);
char abc[8];
...
}

実際、char abc[8]私の場合は役に立たない（デッドコード）。しかし、char abc[8]カーネル コードに . をコメントアウトするchar abc[8]と、結果が正しくなり、カーネルの実行時間が短くなります (697856 ns)。カーネルのコンパイラはデッド コードを一掃しませんか?

上記は、私が繰り返すことができる明示的な例です。また、まったく同じ環境で異なる時間に 1 つのプログラムを実行すると、異なる結果が得られるという、より奇妙なケースにも遭遇します。

それはメモリ割り当てに関連していますか..？誰でも問題を見つける方法についてアドバイスをもらえますか?

ちなみに、oclDeviceQuery の出力情報は以下の通りです。 Platform Version = OpenCL 1.1
CUDA 4.2.1、
SDK Revision = 7027912

私のOSはWindows XPです。

今日は 2012 年 7 月 17 日で、この問題は解決したと思います。

  1. カーネル ソース ファイルで #include を使用しないでください。

  2. カーネル ソース ファイルで超長行を使用しないでください (たとえば、カーネル ソース ファイルの行データを生成するプログラムを作成します)。

4

1 に答える 1

1

そうです、それは何の影響も与えないはずです。

ただし、それは実際のコードではありません。これらのランタイムを考えると、カーネルは単純なものではないのではないかと思います。おそらく、ローカル変数を制限を超えてプッシュしている可能性があります。つまり、変数を低速のメモリに格納する必要があり、実行時間が長くなります。

初期化されていない変数のバグがどこかにある場合、そのようなことも動作の変化を引き起こす可能性があります。高速ストアでは、たまたま機能する値を取得します。遅いストアでは、何か他のものを取得します。

この理論を確認するために、他のローカル データ構造を削除して、同じ効果があるかどうかを確認します。それ以外の 8 バイト以上のものは、同じ効果を持つはずです。

...もちろん、OpenCL の実装でバグを見つけた可能性もありますが、それは簡単に確認できます。CPU などの別の OpenCL デバイス用にカーネルをコンパイルするだけです。コンパイラが異なれば問題が異なるため、これはとにかく実行する価値があります。

それ以外は、標準のデバッグ手法に戻っていると思います。

ところで：質問のある時点で、abs[8]ではなく配列を呼び出しますabc[8]。それはタイプミスだと思いますが、そうでない場合は、abs名前が関数と衝突するため、問題になる可能性がありますabs()。それは愚かなコンパイラを混乱させる可能性があります。

于 2012-05-31T11:09:39.117 に答える