Should I file a BUG REPORT and include the .acf file?

Thanks,
Scott

Kev,
Are you running the Vulkan-driver? It would be nice to know if it performs same, better, worse than the Game or Studio drivers, and if not, what does this driver do that it would be a separate driver offering?

Could you add a date and time at the beginning of a blog post entry? I appreciate that this blog exists.

Yes, yes and yes.
1. With the right code, we can predict 100% of the pipelines. It is definitely deterministic.
2. Settings changes force a rebuild, so there’s no edge case there.
3. Third party content simply changes the subset of all possible pipelines that we will use – that universe is bounded and finite and NOT “sized” by content – e.g. the total pipeline count is calculable and known in the unextended sim and doesn’t change when third party content is added.

Basically for each material introduced in ANY art asset anywhere, we _may_ build one or more pipelines as needed if they don’t already exist, based on the cross-product of the current rendering settings and that material. We de-dupe, e.g. your 400th orthophoto texture isn’t making new pipelines, it’s the same as the other 399.

>> So we try to build only the pipelines we need. If we build too many, we slow load, and if we build too low, you see this error.

This doesn’t sound like something where you are 100% certain that you will get all pipelines you need before you start a scene once bugs are ironed out. To me this sounds like “I have a slider where on one side you get fast load time with frequent crashes and on the other long load with barely any crashes.”

Can you, with the right code, 100% predict all the pipelines for a given scenario? Does changing rendering settings during flight force pipeline builds? Is XP11 static in the sense that no 3rd party thing can pull in objects during the scene that weren’t anticipated?

With all the complexity and extendability that XP11 undoubtedly requires, I am amazed that you can predetermine all possible pipelines that are needed during load time.

Vulkan gets us Windows, Linux and Android; DX12 gets us only Windows. Also the SPIR-V tool-chain from Vulkan plays well with GL and Metal — they’re starting to have this for DX HLSL I _think_ but we sort of get the shader side of Vulkan for free.

Given that the driver is now abstracted, we could write a DX12 back-end – I see no indication that it would be better than Vulkan.

Nice to hear! I mean: It’s much better than hearing: “We’ve discovered quite a lot Vulkan errors we have to work around”