お世話になっております。
XSS環境でのテクスチャのMip周りでの質問です。
<br/>
画面に表示されていない、またはされていないほど遠くにあるオブジェクトのテクスチャが、64x64より小さくならずで数多くがメモリに乗っているのを対処したいです。
<br/>
一番下のMipになる距離や条件などはエディタ上での設定やエンジン側で調整は可能でしょうか？
<br/>
テクスチャのMipは1x1のまで作ってる状態です。
<br/>
<br/>
お世話になっております。
本件確認させて頂いたところプラットフォーム関係なく発生する可能性がありまして、
以下の3か所において最小で読み込まれるMipが7として定義されていたため64x64が常駐する形となっておりました。
こちらの対応の理由としましては小さすぎるMipの読み書きによるIOコストが挙げられ、一定のMipまでは読み込んでいる形となります。
該当箇所を変更する事で削減することも可能ですが、IOコストがかかってしまう懸念があるため処理負荷等を確認頂きながらご対応頂く形となりそうです。
※フォーマットによってブロックサイズによる最小サイズが異なるケースがあるため、すべてが1x1までにはならない見込みです。
.\Engine\Config\BaseEngine.ini
MinTextureResidentMipCount=7\Engine\Source\Developer\TextureFormat\Public\Interfaces\ITextureFormat.h(46行目あたり)
struct FTextureEngineParameters
{
...
int32 NumInlineDerivedMips = 7; // NUM_INLINE_DERIVED_MIPS
};
\Engine\Source\Runtime\Engine\Private\TextureDerivedDataTask.h(32行目あたり)
enum
{
/**
* The number of mips to store "inline". This is the number of mips, counting from the smallest, that are
* always loaded and never streamed.
*/
NUM_INLINE_DERIVED_MIPS = 7,
};
お手数おかけしますが、上記対応をご確認頂けますと幸いです。
よろしくお願いいたします。
ありがとうございます！
「インライン」で格納するMIPSの数。これは最小から数えたMIPSの数であり、以下の条件を満たす。
* 常にロードされ、決してストリームされない。
とあるので、これは７のところを１か０にしておけば一番小さい1x1まで使われるという認識で合ってますか？
7の箇所を全て１にしてみたところ
ListTextre上では32x32になってはいますが メモリのサイズが変わっておらずでした。
こちらは、ListTextre側が間違っているのか、そもそもサイズが変わっていないのかがわかりません。
どのようにチェックしたら良いでしょうか？
対処前
2048x2048 (5504 KB, ?), 64x64 (64 KB), PF_DXT5, TEXTUREGROUP_World, /Game/Field/Texture/WaterStorage/T_BG_OBJ_ControlRoomWindow_02_D.T_BG_OBJ_ControlRoomWindow_02_D, YES, NO, NO, 1, 12, NO
対処後
2048x2048 (5504 KB, ?), 32x32 (64 KB), PF_DXT5, TEXTUREGROUP_World, /Game/Field/Texture/WaterStorage/T_BG_OBJ_ControlRoomWindow_02_D.T_BG_OBJ_ControlRoomWindow_02_D, YES, NO, NO, 1, 12, NO
ご確認ありがとうございます。こちら返信が遅くなり申し訳ありません。
前回紹介させて頂いていた箇所変更することで常駐mipを減らすことが可能の想定となっておりましたが、こちらでも通常要求されるWantedmipが大きい事を確認しており、サイズ等の問題も含めて改めて挙動を確認させて頂いております。
進展があり次第ご連絡させて頂きますので、もうしばらくお待ちいただけますと幸いです。
よろしくお願いいたします。
承知しました。
ご対応ありがとうございます。
合わせてlisttextureのCurrentサイズが変わっていない（32x32でも64kなのでサイズ的に64x64のまま？）という現象についてもご対応お願いいたします。
お世話になっております。
本件お時間を頂いており申し訳ございません。
詳細を確認させていただいたところ最低64KBとなっていたのはページサイズによるメモリアライメント対応となっていたようでして、それも含めて7番目まで常駐させる事が効率的となっているようです。
https://learn.microsoft.com/en\-us/gaming/gdk/docs/features/graphics/graphics\-memory\-overview
前回Mipを減らす対応を紹介させていただいたところ恐縮ですが、常駐ミップの削減は難しい状態となるため別のメモリ削減対策がないか確認を行ったところ直近の更新でXBOX向けにメモリを削減する対応(CL45599286)が入っておりました。
こちらテクスチャのLayout情報を削減するものとなっており、テクスチャの数が多い場合メモリ削減に有効な見込みです。
お手数おかけしますが、こちらの方法で削減が見込めないかご確認いただけますと幸いです。
よろしくお願いいたします。
ありがとうございます！
CL45599286を取り込んで確認してみます
ちなみに、このメモリ対策は5.4.4に適用できる対策でしょうか？
一部5.5の対応が必要な対策だったりしますでしょうか？
ご確認ありがとうございます。
CL45599286に関して依存しているCLは確認できていませんでしたが、こちらの対応はUE5.7ベースかつ
間で行われているTexutre作成周りのリファクタリングCL42293826が存在するためマージには注意が必要です。
※以下関数以外で取り込むことでマージと起動を確認しております。
static UE::RHICore::FBaseTextureInitializerImplementation CreateTextureInitializerForWriting(FRHICommandListBase& RHICmdList, const FD3D12DynamicRHI::FCreateTextureInternalResult& CreateResult, const FRHITextureCreateDesc& CreateDesc)
CL42293826を含めると量も多いため将来的にバージョンアップが可能な場合はバージョンアップでの対応が望ましく、
難しい場合は基本的な対応(Bias等で低いMipを利用する、不要なテクスチャがリファレンスされていないか等)での対応も検討いただけますと幸いです。
よろしくお願いいたします。
ご連絡ありがとうございます。
マージを担当してる方に共有します。
お世話になっております。
今回のXSX向けの改修ですが、取り込むのを断念しました。
変更が多すぎて安全に取り込むのができず
また、マスター直前なのでエンジンもアップデートすることも危険との判断です。
状況に関してご共有頂きありがとうございます。
マスター直前といった場合、確かにリスクが高く導入は難しいかと思われます。
二転三転してしまい申し訳ございませんが今回大本のご質問いただいていたような最低mipの常駐を減らす方向も難しいため、
前回紹介させていただいたような基本的な対応による削減でメモリの帳尻をあわせて頂く形が望ましいかと思われます。
お手数おかけしますが、よろしくお願いいたします。