On Tue Dec 5 09:58:48 2023 +0000, Giovanni Mascellani wrote:
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?
Another problem with checking features in the client is it requires a shader scan in `state.c` which is currently skipped if descriptor indexing is fully supported.
Either way, I really want feature information to be passed as a flag enum. Extensions and parameters are both pretty clunky ways of doing it.