2件のHPG18 ショートペーパーの説明
•
1 like•1,114 views
"Deferred Adaptive Compute Shading" "Adaptive Temporal Antialiasing"
Recommended
More Related Content
More from Takashi Imagire
More from Takashi Imagire (20)
2件のHPG18 ショートペーパーの説明
- 1. HPG18 Short papers • Deferred Adaptive Compute Shading • Adaptive Temporal Antialiasing
- 2. Deferred Adaptive Compute Shading Ian Mallett, Cem Yuksel (University of Utah)
- 3. ポイント • チェッカーボードレンダリングと比べて – 同じ時間なら高品質(平均平方二乗誤差で21.5%) – 同じ品質なら速い(4.22倍) [Vlachos 2016]との比較
- 4. ABSTRACT / INTRODUCTION • Deferred Adaptive Compute Shading • シェーディングrateの適応型サブ分割スキーム • 周辺の画素の情報から色を計算するか近似す るか決定して処理を行う – 劇的にシェーディング計算量を減らせる • 分散が低いところは粗く • 分散が高いところは細かく
- 5. 関連研究 • deferred shading [Saito and Takahashi 1990] – 重なった部分のシェーディングを取り除いた • Decoupled shading – [Ragan-Kelley et al. 2011] – 色計算と深度情報の粒度の分離 – [Liktor and Dachsbacher 2012]：GPU実装 – [Clarberg et al. 2014, 2013]：投機的アーキテクチャ – [Crassin et al. 2015; Kerzner and Salvi 2014]：同様の 研究
- 6. 関連研究 • Adaptive, Multi-Rate Shading Pipeline – [He et al. 2014] • 影などを鮮明に • 空想のハードウェアで – CPS [ Vaidyanathan et al. 2014] • シェーディング結果を粗ければ複数に分配 – [Stengel et al. 2016] • 知覚を考慮 • 現在のハードウェアでの実装無し
- 7. 関連研究 • checkerboard rendering – [Mansouri 2016; Wihlidal 2017] • [Vlachos 2016] – VRでの周辺視野領域について4x4で市松模様で 抑制してバイリニアで再構築
- 8. チェッカーボードレンダリング • 画面解像度と比較してGPUの計算能力は足 りない – 市松模様に飛び飛びで色を計算。深度とID値を 用いて計算していないが画素の色を補間 – 市松模様はフレー ム毎に入れ替えて
- 11. note • レベルごとのパターンを今回のようにした分け – V-Rayの細分割サンプルと同じ[Chaos Group 2015] – 他のレイトレアプリでも使われている[Steinberger et al. 2012] • 細かなレベルでシェーディングするかの判断 – 周辺のピクセルとマテリアルIDが異なる – 分散が閾値以上 • 今回のケースなだけで、各自工夫してよい
- 12. コツ • 単純に実装するとGPU内のwarpが爆発 • 効率化のために、コンピュートシェーダを使って処理を分 ける – シェーディングを必要とするピクセルを選別 – 識別されたピクセルをシェーディングする • 選別方法 – ワープごとにk(warpの幅)個の画素を割り当てる – 「シェーディング基準」でシェーディングすべきか判定 – 補間でよいならすぐに色を確定 – 色を計算すべきなら、2k-1要素のリングバッファに画素を追加
- 16. 結果：Nyra character scene • 8K×8K shadow map (PCSS) • テクスチャの参照数を増やすとDACSの方がより効率的に レンダリングされた – ピクセルのコヒーレンス性は下がったが、シャドウマップのテク スチャキャッシュの効率が上がっているかららしい – 結論：DACSはテクスチャ参照が増えると有利
- 17. 結果：Windmill scene • 非常に薄いジオメトリ • Gバッファに記録されていれば細かく描画 – テクスチャの細かい模様の部分では難しい – MSSIMは> 0.999 – パフォーマンスの 向上は1.90倍
- 18. DISCUSSION AND FUTUREWORK • マテリアルIDと分散ではなく、他の原理/知覚 に基づけばよいものができるでしょう • テクスチャキャッシュには悪く、コンピュート シェーダによるオーバーヘッド – シェーディングの複雑さが高く、シェーディング レートが低いシーンでは、計算量の節約がオー バヘッドを上回ってしまう
- 19. まとめ • Deferred Adaptive Compute Shading を提案 – シェーディングの量を減らせる – 実際の製作現場での高ジオメトリ・テクスチャ・ シェーディング詳細のシーンで支持されるのでは?
- 20. Adaptive Temporal Antialiasing Adam Marrs, Josef Spjut, Holger Gruen, Rahul Sathe, Morgan McGuire （NVIDIA）
- 21. ポイント • ゲーム向け適応型リアルタイムスーパーサンプリング – 適応型レイトレでTAAを拡張 – ゲームエンジンとGPUレイトレとの高親和性 – TAAのゴーストを除去、8点SSAA(30フレ用のリソースで)
- 22. 背景 • アンチエイリアシングは最も基本的で困難 • ほとんどのレンダリング方法は、ピクセル内 の点でシェーディングをサンプリング – サンプリングされた点がピクセル全体を代表しな い場合にエラーを生成
- 23. 解析的レンダラー • エイリアシングの問題を避ける ことができる – がケースが限定的 • NSAA[Auzinger et al. 2013] – NSAA:Non-Sampled Anti-Aliasing
- 24. エイリアシングについて • エラーの現れ方 – ギザギザのエッジ – 空間ノイズ – ちらつき（時間ノイズ） • エラー隠蔽しようとすると、 ぼかしやゴーストの アーティファクトが生まれる – 空間的 • MLAA [Reshetov 2009]、FXAA [Lottes 2009] – 時間的 • SMAA [Jimenez et al. 2012]、TAA [Karis 2014]
- 25. 固定サンプル数での アンチエイリアシング • サンプリング密度を上げれば問題は解決するが、リアルタイムの手ごろなコストで解 決する方法はない • スーパーサンプリング（SSAA） – サンプリング数に比例してコストがかかる – サンプリング数の平方根で品質が向上 • マルチサンプリング – MSAA, CSAA, SBAA [Salvi and Vidimče 2012], SRAA [Chajdas et al. 2011] • コストを下げるが品質も下がる – 集約手法：DCAA [Wang et al. 2015], AGAA [Crassin et al. 2016] • よりコストを下げるが、品質と速度の問題は依然として存在 • マテリアルの事前フィルタリング – ミップマップ、ジオメトリLoD、シェーダLoD – 帯域の制限で問題を改善するが、システムを複雑にするだけ ゲームでのAA：複数の手法を組み合わせる – 複雑になる – アーティストのチューニングが必要
- 26. 今回の挑戦 • 固定サンプル数を止める – オフラインでは以前から知られた方法 • [Whitted 1980] – [Holländer et al. 2013] • AAするピクセルを選別 – 粗いシェーディングと 高解像度ジオメトリパスから – 10%の高速化 – サンプル数はSSAAの半分 • 問題：わずかなピクセルしか 影響しなくても、全てのジオ メトリを処理する必要がある
- 27. アイデア • アダプティブサンプリングにDirectX Rayを組み 込む – レイトレとのハイブリッドは先行研究あり • [Barringer and Akenine-Möller 2013] • しかし、レイトレとラスタライズ用でデータを重複してもっ ており、効率的ではなかった – DXRで両方のシステムのデータ構造とシェーダの 相互運用性が初めて実現できた • ブラーやゴーストがない適応型TAAを実装した
- 28. 従来のTAA • 今日のゲームのデファクトスタンダード • サンプリング点をピクセル内で周期的にずら して指数加重移動平均で重ね合わせ – 静的なシーンでは、スーパーサンプリングの品質 – 動的なシーンでは、移動分 をずらしてサンプリングする ことで対応
- 29. TAAの問題 • 生じる問題 – オブジェクトの動きで画面が隠れると誤って表示 • カメラの動きでも同様 – サブピクセルの細かな特徴が表現されない可能性あり – 透明な物体があると、後ろにある物体の動きを隠す – 影と反射の移動は動きベクトルでは追えない • 失敗した結果 – ゴースト – ジャギー、ちらつき、ノイズ • 元のエイリアシング • 対策 – 近傍との比較でイレギュラーを発見 • 方法のまとめ[Salvi 2015] • 汎用的な解は現時点ではない
- 30. 新しいアルゴリズム • ほとんどの場合はTAA • 失敗しそうな場所と理由をマスクとして出力 – 2つの半精度の符号なし整数値 • ピクセルのAAメソッド（0 - FXAA、1 - TAA、2 - ATAA） • ピクセルが前のフレームでATAA経由でレイトレーシン グしたかを格納するピクセル分類履歴 • 不良ピクセルを代替物で置き換える
- 33. セグメンテーションマスクの作成 • 全画面TAA処理後 • TAAの失敗の検出 – 動きベクトルで以前のピクセルが隠れていないか – ピクセル分類履歴 • 最近レイトレされたなら数フレームレイトレする – ちらつき低減 • ピクセルの動きベクトルの変化が激しければ履歴はリセット – ピクセルの近傍を検査 • 輝度の時間変化を計算 – エッジ検出でエッジの大きさを閾値と比較 • 3x3ソーベルフィルタでの深度変化
- 34. レイトレース • 8×, 4×, 2× のどれか – MSAAのn-rooksサブピクセルサンプリングパターン • 時間的なジッタリングはしない（future work） • ラスタライズと同じHLSLコードでシェーディング • ? DXR Ray Generation Shaderでは forward-difference derivative ができないので、最も 高いテクスチャの解像度に強制するために無限大として取り扱った – 映画製作で最高品質の場合にこうしている – マテリアルのエイリアシングはSSAAだのみ – ミップマップレベルを解析的に選択したり、線微分を使用するために、レイの距離や方向を使う • コスト：ピクセルあたり1サンプル未満のレイ – ほとんどがATAA(黄黄)でなくTAA(青)のため – シーンの6％に対して8Xレイトレーススーパーサンプリングするのに0.5本/ピクセル未満のコスト • 品質は、全てのピクセルで8×SSAAしたものに匹敵 • セグメントの境界はアルゴリズムが違うので、最終結果ではフリッカーが起きるだろう
- 35. 結果 • NVIDIA Titan V GPU – NVIDIA RTX enabled 398.11 ドライバー • Unreal Engine 4 • Windows 10 v1803 • Microsoft DXR
- 37. 評価 • 1920×1080 @ NVIDIA Titan V GPU • レイトレーシングピクセル(107,881ピクセル (5.2%)) – 18.4ms: 8×スーパーサンプリング – 9.3ms： 4×スーパーサンプリング – 4.6ms： 2×スーパーサンプリング • FXAA – 初期フレーム：0.75ms – だんだんと0になる – 通常のカメラの動きでは、FXAAは5%未満 • 全体速度 – 典型的なシーンでUE4の33ms(30FPS)内で正常に動作 – 16ms(60FPS)では2×、4×スーパーサンプリングが可能 • 影は1sppのレイトレーシング – 将来はパフォーマンスが向上 • DXRはWindows 10 v1083の実験的な機能 • ランタイムとドライバの最適化がまだ不十分
- 38. まとめ • エイリアシングは重要な問題 – オフラインでは適応型サンプリングで解決 – リアルタイムでは効率的なラスタライズ法がなかった • GPUレイトレーサーでもデーの重複という無駄が存在 – DXRはレイトレースとラスタライズをハイブリッドする • アンチエイリアスをどうするかはまだ非自明だった – 1sppの情報を受け取った際にそのコストからそれぐらいスーパーサンプリングを減らすか • 上記の問題に対する解法を提案 – 実用的なゲームエンジン内で動作 – 第1世代のリアルタイムレイトレーシングのハードウェアとソフトウェアでもリアルタイムに動作 – 最初にレイを飛ばして適応度を決めるのではなく、セグメンテーションマスクを構築 • エイリアシングを検出して数フレームでコストを償却 – 隠れた部分はFXAAで処理 • 次のフレームはTAAを使うことでコストを削減 • 今後数年でアルゴリズムを磨かないといけない – 現行のパフォーマンスでゲームに即座に広範囲に展開することはできない – DXR APIをサポートする主流のゲームGPUもまだない – ドライバー、GPUとともにリアルタイムレイトレエコシステムを作らないといけない