mankrip wrote:And not needing driver-supplied compilers should also help Linux gaming. I have a feeling that the Linux versions of many graphics drivers are poorly coded, specially in the case of IGAs.
Well, they'll be able to just write poor bytecode interpreters instead…
It's important to realize that it's not actually bytecode interpretation going on here.
What really happens is that it's a two-step compilation process.
Step 1 takes the plain-text shader source and compiles it to a
vendor-neutral intermediate representation. This step can (but doesn't have to) carry out optimizations like dead-code removal, instruction reordering, etc. It also does syntax-checking and all of the other really slow validation stuff (in D3D it will also validate it against hardware capabilities; I don't yet know whether or not the SPIR-V compiler will do this). The really critical part of this step is that the end result is a known-good binary representation of the shader source. This step happens outside of the driver via a separate tool and doesn't even need D3D to be initialized (it can be a command-line tool).
Step 2 takes that intermediate representation and
compiles it again to a
vendor-specific shader. Because it's already syntax-checked, because certain pre-validation is already done, because certain optimization may be already done, this step can be really really fast. This step happens inside the driver and does need D3D to be initialized.
What you actually ship with your game is the IR version of the shaders. So if you have hundreds or thousands of shaders, all of the slow stuff is skipped over when your game launches because all it needs to do is load and do the final compilation of the IR.
In the open-source world this doesn't preclude also shipping the shader source code. You can even do the compilation-to-IR as part of your game's installer if you wish.
What's really cool about Vulkan is that the bytecode specification is going to be open and (presumably) there is going to be a single open-source reference implementation of the GLSL-to-bytecode compiler. I expect that vendors may eventually build their own compilers with vendor-specific optimizations in them (and it may be required to use them as part of a vendor logo program) but for the rest of us, that means we're going to have consistently compiled shaders: no more wild-west. It also means that all we need to feed the driver is valid bytecode; it's not going to matter how the bytecode was generated; we could use the reference compiler, we could use a different compiler, we could hex-edit it by hand, whatever. So long as the bytecode is valid the driver will create a shader from it.
What it also means is that we're going to start seeing bytecode to high-level-language converters. It will be possible to author shaders in GLSL, compile them to SPIR-V, then convert that to a HLSL version of the shaders, all tool-driven. We may even see converters to-and-from SPIR-V and D3D bytecode. That's going to colossally enhance portability of games and everyone will win.