为什么PC包里PSO创建时间会这么久？这样导致依赖他的cmdlist一直在crash scope里，最终超过数量crash
[Image Removed]
Hi,
我们近期发现在581.xx的驱动上，核数比较多的时候，会造成并行编译PSO变得很慢，从而造成time out（因为NV在驱动里增加另一个锁，导致并行性变得非常差），不过我看你们的驱动是576.28，我不太确定是否有同样的问题。你可以先试试调整
r.pso.PrecompileThreadPoolPercentOfHardwareThreads，变小一点，看看是否有改善。
We've been noticing that on high core count machines (like our internal Threadrippers), concurrent PSO compilations get really slow due to contention to the point where a runtime PSO is stuck for more than 40s and triggers a timeout.
另外我们已知的是NV的驱动对于Compute PSO的编译要明显慢于Graphic PSO，所以很多用到Compute Shader的PSO编译时常会很夸张。
所以我们也建议最好要保证PSO Precache和Shader Pipeline Cache起效，避免运行过程中编译PSO，而是要把编译时间尽量放到启动阶段和资源加载阶段。
如果这个功能你们有问题，我们可以进一步沟通这方面的问题。
好的。我们试试
你好，我们也到了类似问题，另外现在D3D12上默认关闭了D3D12.PSO.DiskCache，导致每次启动客户端都要编译（后续编译相对快一些），有没有办法改善呢
我们试了这个cvar。发现用处不大。另外报错的这个PSO是nanite相关的。但是目前nanite默认是不开precache的。有什么建议吗？
Hi，
nanite默认没开precache的设置是哪个？应该不会有这个设置才对。UStaticMeshComponent::CollectPSOPrecacheData应该有处理nanite的情况。
另外D3D12.PSO.DiskCache应该不需要开启，因为现在驱动都有自己的cache，开启和不开启DiskCache应该没有区别才对。
第一次编译pso是非常耗时的，这个也是我们已知的情况，这个我们没有有什么特别好的手段改善，因为主要是驱动层的原因造成的，我们也只能反馈给硬件厂商，看一下有没有什么手段改善。
比方说这里[Image Removed]
此处的改动是暂时不支持GSkipDrawOnPSOPrecaching这个功能，就是不支持 PSO precache还没有结束的时候，用默认材质的shader来渲染。PSO Precache功能还是起效的。