vkd3d: Support SM 6.2 denormalization mode.
There are some open questions here:
- It's lot of code for a relatively minor feature that in theory shouldn't be much more work than passing a handful of flags. Unfortunately SPIR-V has complicated rules on which flags can be passed, so we have to do a fair amount of work to see whether what we would like to request fits the driver's requirements. I couldn't find a way to make it shorter, maybe somebody else can? Or should be just drop support for this altogether? Notice that in principle we'd need to emit denormalization modes not just for SM 6.2 shaders that request one explicitly, but for all shaders, since AFAIU D3DBC/TPF/DXIL shaders have a well-defined denormalization mode even when nothing is explicitly specified, while SPIR-V leaves the choice to the driver. OTOH it might be argued that denormalization mode is unlikely to be relevant for all but very few applications, so we should not go out of our way to support it. Personally I'd like to have it supported, when possible.
- Commit 4/5 regresses a test; AFAICT this is not our bug, we're just exposing a latent bug in RADV (and possibly other Mesa drivers), but certainly we're causing a new end-to-end bug to appear. I can't see any reason why log(+/- 0) should be +infinity when preserving denormals.
- Commit 5/5 enables shader model 6.2 support. My understanding is that this is legitimate, because all the other features in shader models 6.0, 6.1 and 6.2 are either supported or gated behind feature flags which we don't enable (well, we're still unable to support some 6.0 corner cases, mostly forward references, but that's orthogonal and we're already declaring 6.0 support anyway). Is that ok?
- There's a question with what to do when the Vulkan implementation doesn't offer
VK_KHR_shader_float_controlsor some of its features, which is not an uncommon occurrence. Strictly speaking we shouldn't announce shader model 6.2 in the first place; but by that token, as mentioned above, we shouldn't allow device creation at all, since all shaders really need to set some denormal mode. And, again, this looks like a really minor feature and it's unlikely many applications will break if we cheat on the denormal mode, so for the moment I've elected to ignore the extension presence, always announce shader model 6.2 and then go best effort. If and when vkd3d will support some kind of "strict mode" that's a case in which we'd fail device creation, but we're not doing that now. How does that sound?