Are there any other CLs that we’d need in order to avoid this type of miss?
I did find this other thread discussing PSO precaching misses, but they seem to be addressing misses that don’t have this kind of reason listed: [Content removed]
Are those CLs also needed to avoid fast vram precaching misses?
Set r.PSOPrecache.Validation=2 in WindowsEngine.ini
Cook and package a build
Launch the cooked build on a platform that supports FastVram and review the logfile to see the base pass PSO precache miss reasons for a range of materials across vertex factories TGPUSkinVertexFactoryUnlimited, FLocalVertexFactory, FNiagaraSpriteVertexFactory, TGPUSkinAPEXClothVertexFactoryDefault- mostly with MDCStatsCategory = SkeletalMeshComponent, but with some “Unknown” as well (their material names indicate to me that they’re static meshes, however):
Decimal to binary conversion of these flag values shows that the difference is in bit 21, which is the fastvram bit. It’s set in the requested, but not set in the precached PSO.
We might have a bug in how we hash the PSO descriptor, but it would be good to tell me where you got this PSO cache miss log from. Was this on a PC platform or an Xbox One? FastVRAM is only supported on Xbox One, and PSO precaching isn’t necessary, so it is unclear how you arrived at this.
Oh man yeah. This is entirely on PC; we’re not even trying to support Xbox One. There’s nothing related to fastvram in any *ini file from a quick search, so I would appreciate any assistance determining how I arrived at this haha
At first glance it doesn’t seem like there’s any check on SupportsFastVRAMMemory in the code for FFastVramConfig, or in any downstream usage of GFastVRamConfig to determine texture creation flags.
But it looks like PSOPrecaching should just ignore those flags anyways based on RelevantRenderTargetFlagsEqual and RelevantDepthStencilFlagsEqual?
It’s also possible that the fastvram mismatch is only being reported because the miss is happening for some other reasons- I do have some stuff to clean up first and will report back if it’s still missing when the fastvram mismatch is the only remaining difference
But it looks like PSOPrecaching should just ignore those flags anyways based on RelevantRenderTargetFlagsEqual and RelevantDepthStencilFlagsEqual?
Yes, that sounds about right. I do not see a reason why FastVRAM would play into this. Since you mentioned that you still need some time for cleanup, I will put the case into Pending until it is done. Feel free to reply to this ticket once you have more details to share, and we can take another look.
Update - Once we fixed the other issues that were causing misses, those materials no longer appeared in the logfile despite no change to the vram-specific code. So it seems that the VRAM differences aren’t sufficient to cause a PSO precaching miss on their own. You can go ahead and close this question.
While you’re here though, I noticed that we’re getting PSO misses on WorldGridMaterial. I know this is because the material isn’t loaded yet so we have to rush and compile WorldGridMaterial for the VF/mesh as a placeholder. Is there a cvar to either enable precaching of the material fallback for everything? Conversely, is there a cvar to skip the placeholder material?
Ok, that might have been a transient issue of some sort. I am glad that it resolved on its own, more or less
As for your questions, we currently do not create a fallback material for every component, but if you turn on r.PSOPrecache.ProxyCreationDelayStrategy, you should at least be able to get the benefits of a fallback strategy for static and skinned meshes. Also, make sure you have r.PSOPrecache.ProxyCreationWhenPSOReady on simultaneously, or the flag will be ignored. On the flipside, there is no way of skipping the creation of the placeholder material without making code changes to the engine, as far as I can tell. I hope that helps at least a little bit
FastVRAM is a flag on the render target and thus PSOInitializer - it’s not really used in the d3d12 PC PSOs or during the hash computation as you found out already. But if there is a PSO miss it will report closest matching PSO for the same shader setup if precached. Then it will report everything which is different without taking the RHI specific flags into account, so that’s perhaps a bit confusing. This can be safely ignored and will see if we can remove it from the reporting somehow.
WorldGridMaterial (default) should be precached for all possible common permutations during startup. I guess it’s using the default material because the required PSO is still compiling. Would be good to know what PSO permutation of WorldGrid it’s missing because is should be precached during boot, except if it’s a special permutation coming from non manual vertex fetch where the vertex input layout is important. We can’t really compile them for all possible vertex layouts because that would end up in 1000s of them sadly enough. We just have to stop using manual vertex fetch - which is still used for a few vertex factories.
You can go ahead and close this question.