What we can do is some extension to our tests that will check state objects for initial values, this will only cover statically initialized ones at first. I don't think it should necessarily render anything.
Right.
Unfortunately this is tied to d3d API too much, and we'll have to provide some sort of dxvk-like layer.
Are there parts in particular that you're concerned about there? Fundamentally, there doesn't seem much conceptual difference between e.g. declaring some sampler state using "[sampler]" in a .shader_test, or doing the same using an effect.
The D3DX effect interfaces do quite a bit more than just parsing effects, of course, but I don't think vkd3d necessarily needs to replicate all of that. If vkd3d could accurately parse effects, something like D3DX in Wine could build its state management on top of that. (For example, d3dx9_create_object() in Wine's d3dx9_36 creates shaders while parsing the effect, but it doesn't need to work that way; it could also create those shaders based on the shader bytecode contained in an effect description it got from vkd3d.)
I was thinking we might start using d3dcompiler for d3d10/d3d9 effects tests, once the compiler is capable enough. That would validate at least something, and would be stable enough because of the imported vkd3d.
Are you talking about Wine tests here? Or in vkd3d? I imagine we could prototype some effect parsing code inside the shader runner before exposing a public API for it.