制限がほぼ無くなったような印象です。パフォーマンス等は調べてませんがかなり応用が効きそうです。使えないので、今まで使用してきた下記のコードが動きません。);一応対応してみました。);シェーダーは下記の通り。同等の結果になりました。同様ブロック状のノイズが生じています。あらゆる面で負荷の低減が行われています。同期も暗黙に行わずアプリケーションに委ねる自動化されていると便利ですが、アプリケーションによっては内部の仕組みが見えづらく、最適化の妨げになる場合があります。低レベル化は、オーバーヘッドを減らすと同時に用途に合わせて最適化が出来る範囲が広がりました。具体的にどのあたりがこれまでと異なっているのか、いくつかまとめてみます。同期も表面上見えません。いくつでも生成可能でスレッド化も容易です。登録することで行います。作っておくことも可能です。完了は自分で判定する必要があります。直前まで内容を確定できません。負担が大きくなります。判定など負荷のかかる処理を予め済ませておくことが可能。負担を大きく減らすことに繋がります。毎に決められた数のスロットがあります。ユーザーサイドで用意します。割り当てるなどマッピングの自由度も高くなっています。事前に生成しておけるため動的なコピーも減らせます。参照する場合など、リソースの依存が発生する場合があります。実行は並列化されるので、複数の描画命令が部分的にオーバラップする可能性があるからです。依存が発生した場合の完了待ちやキャッシュの同期はドライバの役割でした。命令を挿入する必要があります。