Do we use spirv-val?

[khyperia]

(for end users, for development we're definitely going to use it) - this came up in #31

Say, for example, that the user does something invalid under the current capabilities - e.g. use OpBitcast on a pointer without the Addresses capability, or a storage class that's unsupported. We have two ways of detecting this error:

1. Detect this when we're compiling, and give an error immediately.
2. Run spirv-val on the result binary, and report any errors as rust errors.

There's a trade-off here: 1 takes way more work, and 2 produces lower quality errors. So, opening up a design issue to talk about it.

---

Of course, the answer might be, as always, a mix of the two. For example, we could try to detect all errors while we're compiling, but realize that there will be holes, and still run spirv-val on the result - and when spirv-val detects something that we don't, add in a check for that in the compiler.

[Jake-Shadle]

but realize that there will be holes, and still run spirv-val on the result - and when spirv-val detects something that we don't, add in a check for that in the compiler.

That seems to me like the most pragmatic path forward both in the short and the long term.

[Jasper-Bekkers]

I think it's fairly difficult to keep / stay up to date with whatever validation rules Khronos comes up so I think a mix would be useful. I would think a spirv-val error would indicate a compiler bug (most likely). I think DXC also runs the validator after codegen to detect compiler bugs.

One other thing is that whenever you load up a spirv shader in Vulkan - it's validation layers will also run spirv-val (if they're enabled).

[khyperia]

Conclusion: yes, we are going to run spirv-val on user's machines on all outputs. This has been implemented in code already.