9

編集: OpenCL または計算シェーダーの使用に関するヘルプをまだ探しています。OGL 3.3 を使用し続け、OGL 4.3 と OpenCL 1.2 の不適切なドライバー サポートに対処する必要がないようにしたいのですが、2 つのうちの 1 つを使用せずにこのタイプのシェーディングを行うことは考えられません (ライトとタイル)。GPGPU を使用せずにタイルベースのカリングを実装することは可能ですか?

OpenGL 3.3 で遅延レンダリングを作成しました。現在、ライト パスのカリングは行っていません (すべてのライトに対してフル スクリーン クワッドをレンダリングするだけです)。これには（明らかに）大量のオーバードローがあります。(場合によっては ~100% になることもあります)。このため、ライト パス中のパフォーマンスを改善する方法を検討してきました。(ほぼ) 誰もが考える最善の方法は、スクリーン スペース タイルを使用してシーンを選別することです。これは Frostbite 2 で使用された方法でした。SIGGRAPH 2010 での Andrew Lauritzen のプレゼンテーションを読みました ( http://download-software.intel.com/sites/default/files/m/d/4/1/d/8 /lauritzen_deferred_shading_siggraph_2010.pdf ) であり、その概念を完全に理解しているかどうかはわかりません。（そして、それが他の何よりも優れている理由、そしてそれが私にとって優れているかどうか）

プレゼンテーションで、Laurtizen は、シーンをカリングするためのライト ボリューム、クワッド、およびタイルを使用したディファード シェーディングについて説明します。彼のデータによると、タイル ベースの遅延レンダラーが (群を抜いて) 最速でした。なぜなのかはわかりませんが。タイルごとにすべてのライトがまとめられているという事実と関係があると思います。プレゼンテーションでは、G バッファを 1 回読み取ってからライティングを計算するように指示されていますが、これは私には意味がありません。私の考えでは、これを次のように実装します。

for each tile {
  for each light effecting the tile {
    render quad (the tile) and compute lighting
    blend with previous tiles (GL_ONE, GL_ONE)
  }
}

これには、G-Buffer を大量にサンプリングする必要があります。それを行うと、すべてのライトに対して画面に合わせたクワッドをレンダリングするのと同じ（悪くはないにしても）パフォーマンスが得られると思います。言葉遣いからすると、次のようなことが起こっているように思われます。

for each tile {
 render quad (the tile) and compute all lights
}

しかし、一部の GPU でフラグメント シェーダーの命令制限を超えずにこれを行う方法がわかりません。誰でもこれで私を助けることができますか？また、ほとんどすべてのタイル ベースの遅延レンダラーが計算シェーダーまたは OpenCL (ライトをバッチ処理するため) を使用しているように見えますが、これはなぜですか?これらを使用しなかった場合はどうなりますか?

4

1 に答える 1

4

しかし、一部の GPU でフラグメント シェーダーの命令制限を超えずにこれを行う方法がわかりません。

それはむしろ、あなたが持っているライトの数に依存します. 「命令の制限」はかなり高いです。通常、退化したケース以外では心配する必要はありません。100 個以上のライトがタイルに影響を与える場合でも、ライティングの計算が命令の制限を超えない可能性はかなり高くなります。

最新の GL 3.3 ハードウェアは、フラグメント シェーダーで少なくとも 65536 個の動的命令を実行でき、おそらくそれ以上です。100 個のライトの場合でも、ライトあたり655 命令です。カメラ空間の位置を計算するために 2000 の命令を使用しても、ライトごとに 635 の命令が残ります。GPU で直接 Cook-Torrance を実行していたとしても、おそらくそれで十分です。

于 2013-04-14T00:44:36.210 に答える