[chubs]

Thanks so much for explaining how that works :)

Is it just me or does decompiling the binary SPIR-V to ESL/HLSL source code then recompiling sound like a recipe for massive inefficiency? Or in practice does it work out pretty nicely?

[robmaister]

Yes, it's absolutely inefficient but for those platforms it's the only way to execute your own code on the GPU. Metal has a bitcode format that I know nothing about and I believe older DirectX had some intermediate format that was binary. Both are proprietary and only documented via reverse-engineering, so they're not great targets.

Most of the extra cost of feeding in SPIR-V could also be offset if you generate the text shader code at compile/packaging time so that those builds don't have the original SPIR-V in them.

[kvark]

It's not absolutely impossible. DXBC was well reverse engineered, and DXIL could also be a direct target for translation. It's up to future work, which for us also includes writing an in house shader converter as a substitute to SPIRV-Cross.

This isn't a big concern at the moment though, since most of the shader loading/compiling time is spent by the driver receiving the result, not us translating it.

Generating a text shader at packaging time is certainly an option to explore, especially for self-contained users like WebRender. The trouble here is that we adjust the shader code based on the pipeline and pipeline layout, so we can only really start translation at the run/init time, unless we start pre-packaging a set of "popular" configurations (which is feasible for WebRender).