アカウント名:
パスワード:
概略を示したプレゼン資料(PDF) [khronos.org]によると、・ユーザ側は複数作成可能なコマンドキューを作って、エンキューする・システム側は、別のスレッドでエンキューされたコマンドをGPUに投げると言う感じのようで、これがタスク単位でコマンドをGPUに投げてるのか、そもそも特定のdaemonを立ち上げておいてエンキューの後でdaemonが読み取ってくれるのかが今ひとつ読めないですね。まぁ、最終レベルのコマンドやコンテキストの管理はXやWayland,Windowsのドライバにまかせてしまうから、実際にはタスク単位でコマンドをGPUに投げるスレッドを立ち上げてるのかも知れませんが。
後、GPU側でプログラムを動かす場合は、SPIR-Vと言う名前で、今までのようなOpenCLやGLSLの生テキストから直接コンパイルするのではなく、プリコンパイルした中間コードからのコンパイルになるようですね。まぁ、そうしておけばOpenCLとGLSLとその他雑多な言語体系のドライバを統合できるから色々都合がいいのでしょう。
# と言う事は、今後の(旧来的な意味での)OpenGLやGLESはVulkanのラッパーになっていくのだろうか?
>・システム側は、別のスレッドでエンキューされたコマンドをGPUに投げるで言うスレッドと、>タスク単位でコマンドをGPUに投げてるのか、そもそも特定のdaemonを立ち上げておいてエンキューの後でdaemonが読み取ってくれるのかのdaemonは別物?
今でもグラフィックライブラリ側で、複数の描画発行先から描画処理を一カ所で引き受けて、GPUが処理しやすいようにソート(Z順だったり使用シェーダなどの属性だったり)した上でGPUに投入してますがその辺をAPI側で面倒見てくれると言うことでしょうか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
SPIR-V (スコア:1)
概略を示したプレゼン資料(PDF) [khronos.org]によると、
・ユーザ側は複数作成可能なコマンドキューを作って、エンキューする
・システム側は、別のスレッドでエンキューされたコマンドをGPUに投げる
と言う感じのようで、これがタスク単位でコマンドをGPUに投げてるのか、そもそも特定のdaemonを立ち上げておいてエンキューの後でdaemonが読み取ってくれるのかが今ひとつ読めないですね。
まぁ、最終レベルのコマンドやコンテキストの管理はXやWayland,Windowsのドライバにまかせてしまうから、実際にはタスク単位でコマンドをGPUに投げるスレッドを立ち上げてるのかも知れませんが。
後、GPU側でプログラムを動かす場合は、SPIR-Vと言う名前で、今までのようなOpenCLやGLSLの生テキストから直接コンパイルするのではなく、プリコンパイルした中間コードからのコンパイルになるようですね。
まぁ、そうしておけばOpenCLとGLSLとその他雑多な言語体系のドライバを統合できるから色々都合がいいのでしょう。
# と言う事は、今後の(旧来的な意味での)OpenGLやGLESはVulkanのラッパーになっていくのだろうか?
Re: (スコア:0)
>・システム側は、別のスレッドでエンキューされたコマンドをGPUに投げる
で言うスレッドと、
>タスク単位でコマンドをGPUに投げてるのか、そもそも特定のdaemonを立ち上げておいてエンキューの後でdaemonが読み取ってくれるのか
のdaemonは別物?
Re: (スコア:0)
今でもグラフィックライブラリ側で、複数の描画発行先から描画処理を一カ所で引き受けて、
GPUが処理しやすいようにソート(Z順だったり使用シェーダなどの属性だったり)した上でGPUに投入してますが
その辺をAPI側で面倒見てくれると言うことでしょうか。