OpenCL は vulkan とどのように関係していますか?
どちらも、複数のスレッドを使用して通信オーバーヘッドを削減するために、キューを使用して、ホストから GPU および GPU からホストに分離可能な作業をパイプライン処理できます。Directx-opengl はできませんか?
OpenCL: 2009 年 8 月 28 日の初回リリース。より広範なハードウェア サポート。ポインターは許可されていますが、デバイスでのみ使用できます。スレッド間で共有されるローカル メモリを使用できます。hello world を開始する方がはるかに簡単です。コマンドがデバイス側でキューに入れられていない限り、コマンドの API オーバーヘッドがあります。暗黙的なマルチデバイス同期または明示的な管理を選択できます。バグは 1.2 でほぼ修正されていますが、バージョン 2.0 についてはわかりません。
Vulkan: 2016 年 2 月 16 日の初回リリース (ただし、2014 年からの進捗)。より狭いハードウェア サポート。SPIR-V はポインターを処理できますか? そうでないかもしれない？ローカル メモリ オプションはありませんか? ハローワールドを始めるのは難しい。API のオーバーヘッドが少ない。暗黙的なマルチデバイス管理を選択できますか? Dota-2 ゲームやその他のゲームではまだバグがあります。グラフィックスとコンピューティング パイプラインの両方を同時に使用すると、さらに多くのレイテンシを隠すことができます。
opencl に vulkan が含まれていた場合、それは 7 ～ 9 年間公開されていません。彼らがそれを追加できるなら、なぜ彼らはopenglのためにそれをしなかったのですか?(おそらくphysx/cudaによる圧力のため?)
Vulkan は計算 API とグラフィック API の両方として宣伝されていますが、計算部分のリソースがほとんど見つかりませんでした。なぜでしょうか?
opencl と同じように、もっと時間が必要です。
ここで計算シェーダーに関する情報を確認できます。
https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#fundamentals-floatingpoint
以下は、計算シェーダーによって管理されるパーティクル システムの例です。
https://github.com/SaschaWillems/Vulkan/tree/master/computeparticles
その下には、レイトレーサーと画像処理の例もあります。
Vulkan には、OpenGL よりもパフォーマンス上の利点があります。Vulkan と OpenCl についても同じことが言えますか?
- Vulkan は別の API と同期する必要はありません。コマンドキュー間のコマンドバッファの同期についてです。
- OpenCL は、共有バッファー (cl-gl または dx-cl 相互運用バッファー) を使用する前に、opengl または directx (または vulkan?) と同期する必要があります。これにはオーバーヘッドがあり、バッファーのスワッピングとパイプライン処理を使用して非表示にする必要があります。共有バッファーが存在しない場合は、opengl または directx を使用して最新のハードウェアで同時に実行できます。
OpenCL は悲しいことに CUDA より遅いことで悪名高い
それはそうでしたが、今では成熟し、cuda に挑戦しています。特に、バージョン 2.1 を使用するすべてのゲーム GPU から fpgas まで、はるかに幅広いハードウェアをサポートしています。たとえば、将来的に Intel は fpga を Core i3 に入れ、それを (soft-x86 core ip) で有効にすることができます。 ) メニーコア CPU モデルは、GPU パフォーマンスと CPU の間のギャップを埋めて、CPU-PHYSX ゲーム体験をアップグレードするか、単純に OpenCL 物理実装にそれを形成させ、ソフトコアの %10 の代わりに少なくとも %90 のダイ領域を使用します。 -%20 有効に使用された領域。
同じ価格で、AMD gpu は opencl でより高速に計算でき、同じ計算能力で Intel igpu は消費電力が少なくなります。（編集：Nvidiaが優勢であるアルゴリズムがキャッシュパフォーマンスに敏感な場合を除く）
その上、私は SGEMM opencl カーネルを作成し、HD7870 で 1.1 Tflops で実行し、インターネットをチェックしたところ、CUDA で人気のあるタイトルを使用して同じパフォーマンスの GTX680 で SGEMM ヘンチマークを見ました! (gtx680/hd7870 の価格比は 2 でした)。(編集: Nvidia の cc3.0 は、グローバル配列を読み取るときに L1 キャッシュを使用せず、カーネルは純粋にローカル/共有メモリ + いくつかのレジスタを「タイル状」にしました)
SYCL は内部で OpenCL を使用していますか、それとも vulkan を使用できますか? それとも、どちらも使用せず、代わりに実装される低レベルのベンダー固有の API に依存していますか?
ここ、
https://www.khronos.org/assets/uploads/developers/library/2015-iwocl/Khronos-SYCL-May15.pdf
言う
(まだ!) OpenCL を持たないターゲットを処理するためのメソッドを提供します。
フォールバック CPU 実装はデバッグ可能です!
そのため、純粋なスレッド バージョン (Java の aparapi に似ています) にフォールバックできます。
SYCL オブジェクトから OpenCL オブジェクトにアクセスできます OpenCL オブジェクトから SYCL オブジェクトを構築できます
OpenGL との相互運用性は SYCL のまま - 同じ構造/型を使用
それはopenclを使用します（おそらく直接ではなく、アップグレードされたドライバー通信を使用しますか？）、openclと並行して開発されますが、スレッドにフォールバックできます。
最小の OpenCL 1.2 組み込みデバイスから最先端の OpenCL 2.2 アクセラレータまで