作成者別アーカイブ: masafumi

Real-Time Rendering 第4版の書籍情報ページが更新

Real-Time Rendering 第4版の書籍情報のページが更新されています.

http://www.realtimerendering.com/

今回の表紙はGDC 2018で発表されたリアルタイムレイトレーシングのデモで使われたスターウォーズのシーンが表紙のようですね.

書籍の目次が公開されていますが,内容が多いので収録が見送られたCollision Detectionと2018年3月に発表されたことで紙に間に合わなかったReal-Time Ray Tracingの章は無料でオンライン上で公開されるようです.

Coarse Pixel Shading with Temporal Supersampling組み込みメモ

はじめに

IntelがI3D 2018で発表した”Coarse Pixel Shading with Temporal Supersampling”(CPS-T)はCheckerboard Renderingに代わる手法になるか気になりまして読んでみました.

Coarse Pixel Shading with Temporal Supersampling
https://software.intel.com/en-us/articles/coarse-pixel-shading-with-temporal-supersampling

この手法は,Checkerboard Renderingと比較して以下のような利点があるとのこですのでその辺見ていきます.

  • Checkerboard Renderingより組み込みが楽
  • Checkerboard Renderingより品質が高い
  • Checkerboard Renderingより速度が速くなるケースがある

手法について

サイトで公開されているデモはMicrosoftのMiniEngineのTemporalBlendCS.hlslを置き換えるような形のものになっています.そのためTemporal Anti-Aliasing(TAA)を実装している環境であれば置き換えが楽にできるようですね.Convert_TAA_to_TS.pdfという移行ドキュメントがデモに入っています.

この手法は,Intelが2011年に発表した”Coarse Pixel Shading”(CPS)の考え方をベースにしていますが,CPSをハードウェアに実装したGPUは現在のところ無いのでいくつか現在のGPUのシェーダで代替できるような回避がされています.

Coarse Pixel Shading
https://software.intel.com/en-us/articles/coarse-pixel-shading

CPS-Tでは,GPU機能のCPSが使えない代わりに1/4の解像度にシェーディングして,前のフレームのレンダリング結果を利用して解像度を復元します.

この復元の手法はTAAに影響を受けてTemporal Supersamplingという手法が生み出されています.このTemporal SupersamplingはTAAのように前のフレームや動きがあるところはMotion Vectorなどを使用しますが,そのほかに低解像度から高解像度化する際の可視性をうる方法としてdecoupled samplingを使用しているということのようですね.

Decoupled sampling for graphics pipelines
http://people.csail.mit.edu/jrk/decoupledsampling/

パフォーマンスについて

論文の中のTable 1と2を見てみます.

Table 1では3つの背景データをライト数変えた結果でBistro(光源は太陽光の1ライトのみ), Sponza(128ライト), San Miguel(128ライト)となります.

Tableの1番左の項目は以下のようなものになります.

  • PS…すべてのピクセルをそのままシェーディングする
  • CBR…Checkerboard Rendering
  • CPS-T…今回の手法

レンダリングの中のZ-prepass, Lighting, Temp-Resolv(PSではTAAの速度)の速度やPS Invoc.(Pixel Shader Invocation.Pixel Shaderの実行回数)などが提示されています.Frame Totalがレンダリングの合計時間です.

Table 1を見て分かることはライトがSunlightのみの状況ではPSが一番速いという結果になっています.逆にライト数が128個のシーンではCPS-Tが勝っています.速度差が大きく出ているのはLightingの個所ですね.なぜ速度差が出るかというとPS Invoc.がCPS-Tが少ないという点にあります.

PS Invoc.が少ない理由としてレンダリングの解像度が1/4になっている点ですね.これによってライトが増えてPixel Shaderの中でライティング計算が増えますが,PSの呼び出し回数が少ないことが効いて速度差がでているわけですね.


Table 1

Table 2はシーンを1つのものに固定してライト数を32~512に変えて比較しています.ライトの数が増えるとごと速度差が出てきます.


Table 2

この結果をみたところPS Invocationの数が少ないことで,1つのシェーダの複雑度が高いケースで速度的なアドバンテージがあることがわかります.

CPS-TはCBRよりもライティングの計算にかかる部分を減らすことで速度を稼ぐというところがポイントになると思います.逆にPSがシンプルであれば速度的なアドバンテージはないとも言えます.

制限

Temporalな手法なので,新たなシーンでは品質の高い絵が出るまで数フレームかかることと動きのあるシーンでは,状況によってはゴーストがでるようなことはあるようですね.サンプルではあまり動的物が少ないので動きのあるものはそれぞれ検証された方がよさそうですね.

おわりに

制限の部分が気になりますが,組み込み自体はTAAを利用しているタイトルでは組み込みは楽かもしれません.CPSに影響を受けていますが,シェーディング自体は1/4でやるだけなのでCPSではなかったりしてTemporal Supersamplingが新しい発明といえるかもしれません.

パフォーマンスのところで書きましたが,速度差がでない環境というのがあるのでモバイルやGPUパワーが弱くシェーダが単純なものの速度を稼ぐには使えないと思います.

しかし,コンソールやPCのハイエンド機などでは面白い手法かもしれないのでTAAをすでに実装しているような環境やCBRの環境では一度載せ替えを試してみるのはいいかもしれませんね.

弱点もありますが,この手法の使いやすさから採用してくるタイトルが今後出てくるかや弱点の改善をした手法などが出てくるかが気になるところですね.

WWDC 18セッション”Metal for Game Developers”の動画とスライド

WWDC 18セッション”Metal for Game Developers”の動画とスライドが公開になっています.

Metal for Game Developers
https://developer.apple.com/videos/play/wwdc2018/607/

スライドの内容としては,

  • マルチコアを活用するコマンドバッファの積み込み
  • MetalでのAsync Compute
  • GPU Driven RenderingとしてMetalでのIndirect Drawなどのテクニックも解説されています
  • iOSデバイスのGPU A11のタイルシェーディングに最適化したレンダリングやプログラマブルブレンディング
  • FortniteのmacOS版,モバイル版のスケーラブルなグラフィックス

WWDC 18 “Metal for Ray Tracing Acceleration”セッション動画とスライド公開

WWDC 18の”Metal for Ray Tracing Acceleration”が公開されています.

Metal for Ray Tracing Acceleration
https://developer.apple.com/videos/play/wwdc2018/606/

AppleのOSでもMetalベースのレイトレーシング環境の概要と使い方が紹介されています.GPUを使用す部分はMetal Performance Shadersで記述ができるようですね.

外付けのeGPUを使ったマルチGPUへの処理の分散などへの対応の話もありますね.

Digital Dragonsの発表 : HDR in Call of Duty

ポーランドのゲーム開発者カンファレンスでのDigital DragonsのActivisionの発表”HDR in Call of Duty”のスライドが公開されています.

HDR in Call of Duty
https://research.activision.com/t5/Publications/HDR-in-Call-of-Duty/ba-p/10744846

スライドは今まで見てきたHDRのワークフロー紹介するものの中では決定版のような内容でアニメーションが入っているのでフルスクリーンでアニメーション再生アリで見るのをお勧めします.

IntelのI3D 2018論文”Coarse Pixel Shading with Temporal Supersampling”の実装とシェーダ公開

IntelのI3D 2018論文”Coarse Pixel Shading with Temporal Supersampling”の実装デモとシェーダが公開になっています.

以前から論文は公開されていましたが,実装したデモプログラムとシェーダが公開になっています.

Coarse Pixel Shading with Temporal Supersampling
https://software.intel.com/en-us/articles/coarse-pixel-shading-with-temporal-supersampling

この手法は現在の4Kコンソールゲーム機で使われているCheckerboard renderingのようにピクセルを削減できるテクニックですが,処理時間が少し速く品質が良いということだそうです.

サンプルプログラムの起動はコマンドライン引数を与える必要があるので添付のreadmeのPDFは読んでおくことをお勧めします.

Digital Dragons 2018の発表から”GPU driven rendering experiments”

こちらもDigital Dragons 2018からですが,Unit 2 GamesのKostas Anagnostou氏の”GPU driven rendering experiments”のスライドが公開されています.

GPU driven rendering experiments
https://interplayoflight.wordpress.com/2018/05/25/gpu-driven-rendering-experiments-at-the-digital-dragons-conference/

Direct3D11世代以降のGPUハードウェア機能(Compute ShaderのほかにHi-Zカリングなど)を活用したカリング手法からのインスタンスを使用した描画命令の発効について解説したものになっています.ただし,Direct3D11世代ではAMDやNVIDIAのようなMulti Drawのベンダー拡張に対応したものが必要になるようです.ただ,IntelでもDirect3D12だとExecute Indirectが動くので問題はないかと思います.

EA SEEDの”Stochastic all the things: Raytracing in hybrid real-time rendering”スライド

ポーランドで開催されたDigital Dragons 2018でEA SEEDからの発表”Stochastic all the things: Raytracing in hybrid real-time rendering”のスライドが公開されています.

Stochastic all the things: Raytracing in hybrid real-time rendering
https://www.ea.com/seed/news/seed-dd18-presentation-slides-raytracing

GDC 2018でDXRの発表の際にEAが公開したPICA PICAのデモの技術的な紹介なのですが,GDCの時の発表よりもより深く解説されていますね.

オープンソースのメッシュ最適化ライブラリmeshoptimizerとメッシュ最適化の話題

はじめに

AMD Compressonator 3.0のリリースの際に,メッシュ最適化や圧縮機能が加わりました.

Compressonator V3.0 Release Brings Powerful New 3D Model Features
https://gpuopen.com/compressonator-v3-0-release-brings-powerful-new-3d-model-features/

メッシュの圧縮にはGoogleのDracoが入ったのですが,最適化はどういったライブラリをベースにしているのか気になって調べてみました.AMDであればTootleが長らく使われていたのですが,GPUOpenのスクリーンショットでTootleではなさそうで,自分が触ったことがあるライブラリの用語が出てきているので最適化部分のソースを見てみました.

https://github.com/GPUOpen-Tools/Compressonator/tree/master/Compressonator/Source/CMP_MeshOptimizer

どうやらCompressonatorではTootleを採用せずにmeshoptimizerを使用しているようですね.今回はmeshoptimizerを紹介しつつもう一度メッシュの最適化とは何かを簡単に復習したいと思います.

meshoptimizer
https://github.com/zeux/meshoptimizer

meshoptimizerについて

meshoptimizerはGPUで描画する3Dの三角形ポリゴンの最適化のためのライブラリですね.特に頂点とインデックスを処理するものになります.こうしたライブラリはAMDであればTootleなどがあります.使用して見た印象ではtootleに使い勝手が近く,すでにTootleを使用しているところは移行がしやすいと思います.

meshoptimizerの機能

meshoptimizerの最適化に関連する機能としては以下です.

  • Indexing
    • インデックスのない頂点データのインデックス化
  • Vertex cache optimization
    • 頂点キャッシュの最適化
  • Overdraw optimization
    • オーバードローの最適化
  • Vertex fetch optimization
    • 頂点フェッチ最適化
  • Vertex quantization
    • 頂点の量子化
  • (optional) Vertex/index buffer compression
    • 頂点,インデックスバッファの圧縮

このほかに三角形リストをストリップ化する機能もあります.現在は,インデックス付き三角形リストがGPUでレンダリングする上では効率的といわれています.meshoptimizerのページでは,ストリップはリストと比較して50%から60%程度インデックスを多く持ち,リスト(三角形当たり1.5から1.8のインデックスを持つケース)が最適化指標のACMR(後述)において~5%程度不利になるということが書かれています.

上記の最適化機能のうち,AMDのTootleではVertex cache optimization, Overdraw optimization, Vertex prefetch cache optimizationの3つがサポートされています.

さらに頂点について最適化度を評価する分析関数があります.この関数を最適化前と後にかけることで,どれだけ変わったかの比較ができます.なんとなく最適化ツールにかけておけばよいだろと思ったときに評価するものがないと実は元データはそれなりに最適化されていてやった意味がないわけですね.

  • meshopt_analyzeVertexCache
    • 頂点キャッシュの分析
  • meshopt_analyzeVertexFetch
    • 頂点フェッチの分析
  • meshopt_analyzeOverdraw
    • オーバードローの分析

meshoptimizerのサポートする最適化

ここからは各機能について解説をしていきます.

Indexing

meshoptimizerでは基本的にインデックスがあるものを最適化するのですが,元データがインデックスがない場合にはインデックスを生成して重複頂点を削除する関数があります.

Vertex cache optimization

頂点キャッシュの最適化は,インデックスを頂点キャッシュを効果的に使うように並べ替えます.この時,頂点データの方は並べ替えはしません.

GPUは,ベンダーごとに16~64頂点の単位で頂点を処理します.この時に,1つの単位で頂点キャッシュが効くので複数の三角形で共有する頂点がある場合には,キャッシュの恩恵を受けます.この最適化はmeshopt_optimizeVertexCache関数に並び替え前のインデックスとインデックスカウント,頂点を入れると並び替えたインデックスを返してくれます.

Overdraw optimization

オーバードローに対する最適化です.オーバードローは,1つのピクセルがカメラから見て対して三角形が重なりあった場合にピクセルシェーダが複数回呼び出されるオーバードロー状態になります.深深度テストが適切に行われる構造であればオーバードローが抑制できますが,適切に行われないデータの場合,この最適化が有効です.

この最適化はピクセルシェーダの負荷が高いケースで,シェーダの呼び出しを抑制することで負荷を軽くすることを目的に行います.複雑なシェーダを適用するものに効果が高いと思います.

オーバードローの最適化を行うにはインデックスのほかに頂点座標を渡す必要があります.この最適化アルゴリズムは頂点キャッシュの効率とのバランスをとるための係数を与えることができます.

Vertex fetch optimization

頂点フェッチの最適化は,頂点バッファを並び替えてメモリアクセスの効率化を行います.GPUは頂点シェーダを実行する前に頂点バッファから頂点属性をフェッチしますが,その際のメモリアクセスの最適化をします.

最適な頂点データの配置はインデックスをもとに決めるためある最適化されたインデックスバッファにて行うとよいようです.

この最適化の注意は,頂点データの方の並び替えが発生する点にあります.たとえば,BlendShapeなどを使う場合,頂点データの並びが変わるとモーフターゲットとベースメッシュの頂点のインデックスがマッチしなくなるかもしれません.

Vertex quantization

頂点の量子化は頂点データのメモリの帯域幅を削減する最適化です.頂点データに必要なメモリを削減する効果もあります.

この最適化は,頂点データの中の座標や法線などを小さいサイズにします.例えば,頂点法線は一般的にXYZの3Dのベクトルで持ちますが,XYZの各要素はfloatで持つことがあると思います.量子化ではこれを10bitにエンコードしてしまうことで10:10:10:2の32bitをに入れてしまいます.こうすることで96bit(float x 3)だったものが32bitになります.

法線の精度が下がるとシェーディングの落ちるケースがありますが,モバイルでは精度よりパフォーマンスを取りたいというケースがありますので有効なことがあるかと思います.

他に量子化が可能な頂点要素だと頂点座標ですが,これは各要素を32bit floatから16bit shortにしてしまうということもありうるかと思います.

量子化はモバイルで有利と書きましたが,通信でデータを取得してブラウザでレンダリングをするWebGLなどでもありがたいかもしれませんね.

(optional) Vertex/index buffer compression

この最適化は,頂点バッファとインデックスバッファ自体を圧縮することでデータを小さくします.これはGPU上での最適化というよりはストレージサイズやローディングなどのケースで有効なものかと思います.

この圧縮はoptionになっていますが,使用するにはいくつか条件があるようです.頂点に関しては,頂点バッファが頂点フェッチ最適化がされ,頂点データが量子化されていることが条件のようです.インデックスに関しては,頂点/インデックスバッファが頂点キャッシュおよび頂点フェッチの最適化がされている必要があり,そうでないケースは圧縮率が下がるようです.

なお,この圧縮に加えてzstdなどでさらに圧縮ということも有効なようです.冗長性を考慮している分,圧縮前のデータからかけるよりも有効に機能するようです.

デコード機能は,1~2GB/s程度で動作し,16bitインデックスバッファであれば5~6倍程度は圧縮できるそうです.これにさらに汎用的な圧縮アルゴリズムを適用することで圧縮率を高められるようです.

圧縮といえばGoogleのDracoがありますが,このことについても触れれています.Dracoでは自分たち独自の量子化などを行った頂点データの圧縮などは不向きなようで,Dracoで圧縮したものを展開してから量子化では処理時間がかかるので,meshoptimizerでの量子化を行うケースではこの圧縮が相性がいいようです.

最適化の分析関数

つづいて最適化の分析関数について見ていきます.最適化の分析関数は,最適化前と後のインデックスにかけてみることでmeshoptimizerの最適化が効果あったか比較するのに使えます.

meshopt_analyzeVertexCache

頂点キャッシュの最適化具合を測ります.キャッシュの最適化はACMRとATVR2つの指標があります.

ACMRは,Average cache miss ratioということで平均キャッシュミス率ということでワーストケースでは3という数字になり,0.5に近いほど良いケースということだそうです.インデックスバッファから三角形を呼び出す際に,各頂点がキャッシュからどれだけ呼び出せるかが,3頂点ともキャッシュにないケースが非効率なケースですね.だいたい,0.5 – 1.5の範囲に収まるのが一般的なケースのようですね.

ATVRCは,Average transformed vertex rationになり総頂点に対してどれだけ頂点シェーダが呼び出されるかの比率になります.1.0が最良のケースだそうです.1つの頂点が頂点シェーダから複数呼ばれるケースというのはインデックスで同じ頂点が何度もあるケースですね.

meshopt_analyzeVertexFetch

頂点フェッチの統計を返す関数です.最善のケースだと1.0を返し,大きくなるほど効率が悪いといえます.この統計は,頂点バッファから読み込んだバイト数と頂点バッファの合計サイズの比ということになります.

meshopt_analyzeOverdraw

オーバードローの統計を取る関数です.この分析は正射影でいくつかの視点で描画します.その際に実際にピクセルシェーダが呼び出される数の比率です.1.0が最善のケースで数値が大きいほどオーバードローが多いということになります.

おわりに

meshoptimizerの機能を見ていくことで頂点データを最適化するアプローチというものが見えてきたかと思います.

今回取り扱った話題の多くは,Xbox 360やPlayStation 3など本格的にGPUを使った開発をする時代にはよく知られていた最適化の基本であったのですが,最近はこうした初歩的な最適化の知識は開発者にとって当たり前のものということなのか読める資料が少なくなってきました.一方で,若い開発者はそうした知識を学ぶための資料がないことで学ぶのが難しくなりました.そういう点では今回は頂点データの最適化の基礎を復習するにはちょうど良い題材でした.

 

実践に関しては,meshoptimizerは比較的組み込みやすいライブラリではありますが,AMDのCompressonatorは分析して表示する機能もありますので,そこから使用してみるとわかりやすいと思います.

 

AMD Compressonator 3.0リリース

AMD Compressonatorの3.0がリリースになっています.

Compressonator V3.0 Release Brings Powerful New 3D Model Features

https://gpuopen.com/compressonator-v3-0-release-brings-powerful-new-3d-model-features/

今回のバージョンからテクスチャの圧縮機能に加えてメッシュの最適化やメッシュの圧縮などが入ってきています.メッシュの圧縮にはGoogleのDracoに対応したようです.