Hi Levan,
Thanks for sharing your findings. The fact that r.PSOPrecaching=0 masks the issue is indicative that a material still remains that may be result in a vertex factory that isn’t used at runtime to generate a PSO permutation (PSOPrecaching doesn’t necessarily create the exact set of permutations used at runtime). As such with PSO Precaching disabled, it would not trigger the issue.
Best regards.
[Attachment Removed]
Hello [Content removed]
my next step is to add logging around the PSO precaching flow to see exactly which PSOs are being requested / compiled shortly before the crash. As soon as I have additional information, I will share the results with you.
Please let me know if there is an existing UE debug path / validation mode that would be especially useful for this case.
Best regards,
[Attachment Removed]
Hi Levan,
That should be helpful in narrowing down which unused PSO variant from which material may be triggering this issue.
Best regards.
[Attachment Removed]
Hello Stephane,
I’m sharing the latest logs from my investigation of the crash.
I added logging in the material PSO precache code and tested a series of builds where I excluded suspected materials from PSO precaching one by one. That did not resolve the issue, and the crash still reproduces.
Based on the results so far, it no longer looks like the problem is tied to one specific material. The current evidence seems to point more toward a broader runtime PSO / Vulkan pipeline issue.
Could you please review the logs and suggest what else I should try to isolate the actual root cause?
Best regards,
[Attachment Removed]
Hi Levan,
Unfortunate, logs weren’t sufficient for the team to isolate this driver specific issue. For further investigation, a repro in binary or uproject form may prove to be a better approach in this case.
Best regards.
[Attachment Removed]