web-dev-qa-db-ja.com

OpenCL、Vulkan、Sycl

OpenCLエコシステムと、vulkanがどのように作用するかを理解しようとしています。

  • OpenCLは、CPUと同様にgpusにもコードを実行するフレームワークであることを理解しています-SPIRにコンパイルできるカーネルを使用します
  • Vulkanは、同じSPIR言語を使用して計算APIとしても使用できます。
  • SYCLは、c ++ 14に準拠する適切な標準としてopenclコードを記述できる新しい仕様です。その仕様の無料実装はまだないことは私の理解です。

とすれば:

  • OpenCLはvulkanとどのように関係していますか? OpenCLはより高いレベルであり、デバイスを抽象化することを理解していますが、Vulkanを内部で使用していますか(または使用できますか)。 (ベンダー固有のドライバーに依存する代わりに)

  • VulkanはコンピューティングAPIとグラフィックAPIの両方として宣伝されていますが、コンピューティングパーツのリソースはほとんど見つかりませんでした。なぜですか?

  • VulkanはOpenGLよりもパフォーマンスが優れています。 Vulkan対OpenClについても同様ですか? (OpenCLは悲しいことにCUDAより遅いことで有名です)

  • SYCLはOpenCLを内部的に使用していますか、それともvulkanを使用できますか?または、どちらも使用せず、代わりに実装する低レベルのベンダー固有のAPIに依存していますか?

24
cor3ntin

OpenCLはvulkanとどのように関係していますか? OpenCLはより高いレベルであり、デバイスを抽象化することを理解していますが、Vulkanを内部で使用していますか(または使用できますか)。

それらは互いにまったく関係していません。

まあ、彼らは技術的に同じ中間シェーダー言語を使用しますが、Vulkanはカーネル実行モデルを禁止し、OpenCLはシェーダー実行モデルを禁止します。そのため、OpenCL専用のシェーダーをVulkanに固定したり、その逆を行うことはできません。

VulkanはコンピューティングAPIとグラフィックAPIの両方として宣伝されていますが、コンピューティングパーツのリソースはほとんど見つかりませんでした。なぜですか?

Khronos Groupは誤解を招くマーケティングの宣伝文句が好きだからです。

VulkanはOpenGLほどの計算APIではありません。 Compute Shadersを使用できますが、機能が制限されています。 OpenCL計算操作でできることは、OpenGL/Vulkan CSからは利用できません。

Vulkan CSは、OpenGLのCSと同様に、1つの目的で使用することを目的としています。グラフィック操作をサポートするためです。錐台カリングを行うには、間接的なグラフィックコマンドを構築し、パーティクルシステムを操作します。 CSは、グラフィカルシェーダーと同じ数値精度で動作します。

VulkanはOpenGLよりもパフォーマンスが優れています。 Vulkan対OpenClについても同様ですか?

計算システムのパフォーマンスは、主にその実装の品質に基づいています。遅いのはOpenCLではありません。あなたのOpenCLの実装が、おそらくそれよりも遅いのです。

Vulkan CSはこの点で違いはありません。パフォーマンスは、ドライバーの成熟度に基づきます。

また、Vulkan CSでcannotするOpenCL計算操作でできることはたくさんあります。

SYCLはOpenCLを内部的に使用していますか、それともvulkanを使用できますか?

クロノスグループから:

SYCL(「シックル」と発音)は、ロイヤリティーフリーのクロスプラットフォーム抽象化レイヤーであり、OpenCLの基本概念、移植性、効率性に基づいています...

はい、それはOpenCLの上に構築されています。

16
Nicol Bolas

OpenCLはvulkanとどのように関係していますか?

どちらも、キューを使用してホストからgpuおよびgpuからホストに分離可能な作業をパイプライン処理し、複数のスレッドを使用して通信のオーバーヘッドを削減できます。 Directx-openglはできませんか?

  • OpenCL:2009年8月28日の初期リリース。より広範なハードウェアサポート。ポインターは許可されていますが、デバイスでのみ使用できます。スレッド間で共有されるローカルメモリを使用できます。こんにちは世界を始めるのがずっと簡単です。デバイス側のキューに入れられていない限り、コマンドの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のために同期する必要はありません。そのaboutコマンドは、コマンドキュー間の同期をバッファリングします。
  • OpenCLは、共有バッファー(cl-glまたはdx-cl相互運用バッファー)を使用する前に、openglまたはdirectx(またはvulkan?)と同期する必要があります。これにはオーバーヘッドがあり、バッファスワッピングとパイプラインを使用して非表示にする必要があります。共有バッファが存在しない場合、openglまたはdirectxを備えた最新のハードウェアで同時に実行できます。

OpenCLは悲しいことにCUDAより遅いことで有名です

しかし、現在は成熟しており、特にバージョン2.1を使用するすべてのゲーミングgpusからfpgasへのはるかに幅広いハードウェアサポートにより、IntelはfpgaをCore i3に入れて(soft-x86 core ip )GPUのパフォーマンスとCPUのギャップを埋めるメニーコアCPUモデルにより、CPU物理演算ゲームエクスペリエンスをアップグレードするか、単にopencl物理実装でシェーピングして、ソフトコアの%10ではなく少なくとも90%のダイ領域を使用する-%20が有効に使用した領域。

同じ価格で、AMD gpusはopenclでより高速に計算でき、同じ計算能力でIntel igpusはより少ない電力を消費します。 (edit:Nvidiaの優位性があるアルゴリズムがキャッシュパフォーマンスに敏感な場合を除く)

さらに、SGEMM openclカーネルを作成し、1.1 TflopsのHD7870で実行し、インターネットをチェックした後、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アクセラレータまで