On Mon Dec 4 07:07:23 2023 +0000, Conor McCarthy wrote:
For features, not extensions, which match up with a d3d12 global flag, it may be better for vkd3d-shader to send these to the client as a set of flags in a new scan struct, so the client can determine if a particular shader is supported before attempting to include it in a pipeline build. This places responsibility on the client not to compile unsupported shaders, but that is true of graphics libraries generally. In addition to int64, this would cover wave ops, native 16-bit, int64 atomics and probably others, and new additions would only require updating the flag enum, instead of passing yet another extension or parameter and reading it in the backend.
I had though about this too, but I'm not sure of what would be the advantage. IIUC what you're proposing is that, instead of having the client declare which features are supported by the environment, we have vkd3d-shader declare which features were used for compiling a particular shader, and leave it to the client to drop the compiled shader if it doesn't support some of the required feature. However the first model seems more useful to me: * if a feature is not known by the client but needed by the shader, in the first case compilation will fail, because the client will not declare it; in the second case compilation will succeed, and the client might fail to notice that that feature is required, because it doesn't know about it; this seems problematic; * it might happen that a feature is not strictly speaking required, because vkd3d-shader can emulate it with other instructions: in this case the first model vkd3d-shader is aware that the feature is not available and can fall back to emulation code, while in the second model vkd3d-shader doesn't know anything and can only use that feature, only for the shader to be dropped immediately after because the feature is not available.
In both case supporting new features amounts to adding a flag to an enum, doesn't it?