There are a couple of cases where we can't use immediates though; relative addressing of constants is one case, and having non-finite values without GL_ARB_shader_bit_encoding is another.
The non-finite values part makes sense to me, but I don't see how relative addressing would require uniforms: is it not possible in GLSL to declare a const array of values and dynamically index that? Or are there actually applications that require dynamically indexing such that we need to return both internal and external constants?
As far as I know nothing prevents an application from mixing these, and it was not uncommon for shader model 1-3 shaders to be written in assembler, so "the HLSL compiler never generates mixed accesses" wouldn't generally be sufficient to stop us from worrying about them.
Makes sense. Although presumably that doesn't mean we have to upload them that way—I was envisioning solving that particular problem by copying both external and internal constants into a temp array in the compiled shader. (But maybe that's more overhead for the lower level compiler?)
It's perhaps also worth pointing out that Direct3D 8 can load shader constants from the vertex declaration using "D3DVSD_CONST"; we have a couple of examples of that in the Wine d3d8 tests.
Is there any reason we can't just implement that on top of wined3d_stateblock_set_vs_consts_f() these days?
It might be possible. The tricky part is probably mostly that D3DVSD_CONST constants override those set by SetVertexShaderConstant(), but we should still need to keep track of constants set by SetVertexShaderConstant() for when we switch vertex shaders.
I actually said wined3d_stateblock_set_vs_consts_f() but meant wined3d_device_set_vs_consts_f(). Point is, I was envisioning handling it in wined3d_device_apply_stateblock().
Right, as I said, the clarification is probably helpful. I'd just prefer phrasing it as something along the lines of "Note that vkd3d-shader maps constant registers in d3dbc sources to CBV registers in the following way: ..., so use enum vkd3d_shader_d3dbc_constant_register here for those.", in order to avoid (seemingly) implying that the "register_index" field works in a fundamentally different way for d3dbc sources.
I think I see what you're trying to get at. I've rewritten this bit in v2; does this seem more reasonable?