clCreateBuffer functionはコンテキスト識別子を取りますが、デバイス識別子は使用しません。 clContext mayには複数のデバイスがあります。clCreateBufferはデバイス固有ではありませんか?
OpenCLバッファがデバイス固有ではないということですか?または、コンテキストには、単一の物理メモリ空間を共有するデバイスのみが含まれていますか?または、おそらく私は何かを見逃していますか?
clCreateBuffer functionはコンテキスト識別子を取りますが、デバイス識別子は使用しません。 clContext mayには複数のデバイスがあります。clCreateBufferはデバイス固有ではありませんか?
OpenCLバッファがデバイス固有ではないということですか?または、コンテキストには、単一の物理メモリ空間を共有するデバイスのみが含まれていますか?または、おそらく私は何かを見逃していますか?
バッファはデバイス固有ではなく、コンテキスト固有のものです。したがって、それらはCLコンテキストの一部であるすべてのデバイスで使用できます。 これにより、各カーネルが異なるGPUで動作するOpenCLカーネルを実行することができます。
質問:「OKですが、実際にメモリはどこにありますか?」 答えは「明らかではありません」です。
ホスト、デバイス、または複数のデバイスに常駐できます。最終的にカーネルの実行に必要なデバイスに常駐します。 CL APIは一貫性を保証しますが、バッファーが確実に所定の位置に配置されるとは限りません。 APIは、将来バッファが必要になると考えられる場合、バッファを別のデバイスに非同期でコピーします。
ただし、手動でAPIにデバイスにバッファを移動するように指示することができます。clEnqueueMigrateMemObject()
ただし、必要に応じて別のカーネルによってAPIを自由に移動することができます。
低レベルAPIのための愚かな設計の選択:-( – einpoklum
この自動コピーが悪い方法で動作するケースはありませんでした。ほとんどの場合、APIはバッファを移動する素晴らしい仕事をします。適切なイベントシステム+メモリフラグを使用する必要があります。それ以外の場合は、バッファを移動/更新する必要があるときにAPIが理解できない場合があります。 – DarkZeros
問題は、デバイスのバッファを必要とし、 。 – einpoklum