Skip to content
Go back

Porting Detroit: Become Human from PlayStation® 4 to PC – Part 3

· Updated:

web

拙訳

  • InstanceIDでもReadFirstLaneでスカラ化する
    • 頂点シェーダの出力とピクセルシェーダの入力の繋がりを見れば、InstanceIDの値がuniformであることは特定可能だが、コンパイラがそれをしてくれるかは不明
    • なので、保険として自前でスカラ化しておく
  • ライティングをスカラ化する
    • [Sousa and Geffroy 2016Sousa, T. and Geffroy, J. 2016. The Devil is in the Details: idTech 666. Advances in Real-Time Rendering in Games course. ACM SIGGRAPH. https://advances.realtimerendering.com/s2016/.]の方法を使ってライティング計算を平坦化する
    • indexをデクリメントしてMaxを取得することで、降順に処理していく
  • コマンド記録をジョブシステムで並列化する
    • PCのドローコール負荷がコンソールより高いことで、レンダースレッドの負荷が相対的に大きくなりすぎたため
    • レンダーターゲットを同じくするドローコールをまとめたrender listにまとめ直す
    • render listあたりのジョブ数はドローコール数に応じて決める
    • コマンドリストはジョブごとに作る
      • 頂点バッファ・インデックスバッファ・デスクリプタのバインドと描画のみ記録する
      • シングルスレッドで記録したときと同じくなるようにソートして記録する
      • コマンドリストはスレッドごとのプールから取る
  • VK_DESCRIPTOR_BINDING_UPDATE_AFTER_BIND_BIT_EXTで更新待ちを回避する
  • バリアを自動化する
    • barrier contextを導入して、バリアをまとめて1回の呼び出しにする
  • 非同期コンピュートの利用は時間的な制約でコンソールより縮小した
    • ライトクラスタの用意やHBAOの計算は非同期でやっている
    • コンソールでは、前フレームのポストプロセスパスと次フレームがオーバーラップしている
  • Vulkan Memory Allocatorを使う
    • 非同期デフラグ
      • 削除も転送もされていないメモリをデフラグ処理に投げて、完了待たずに2フレーム後に新しい場所にメモリを改めて、その後に前のメモリを削除する
      • デフラグ中はメモリが2倍になるが、少量なので、スパイクはほんのちょっとできるだけ
      • デフラグ処理に投げるメモリが少なくても、常時定期的に行われるので、何フレームかかければ全体をデフラグできる
      • テクスチャのコピーも扱うよう修正を加えた
      • レンダーターゲットはデフラグ対象としてはでかすぎるのでメモリプールから取らない
    • エイリアシング
    • カスタムプール
      • 通常は伸長するときにスタッターが発生する
      • 必要十分な量を調査して事前割当を行う