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.
What about other states? Or differences between fx_2 and fx_4/5? To render something, what would naturally be d3d9 or d3d10+ states should be mapped to whatever system shader_runner is using.
Sure. I think that's generally straightforward though. E.g. the shader runner currently uses D3D12_TEXTURE_ADDRESS_MODE_CLAMP for what would be D3DTADDRESS_CLAMP in d3d9. The d3d9 runner already does this particular mapping in the other direction.
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.
I'm talking about Wine tests. We have parsing code already, moving it somewhere else simply delays fixing a problem at hand. Also that will call for some uniform interface for d3dx9 and d3d10+ effects, and I don't see why we would want such extra work.
I think effects parsing is generally useful outside of Wine too, but beyond that, I imagine it's going to be much harder to get effects compilation code merged without the tests to go along with it, than it's going to be to add effects parsing code to the shader runner or vkd3d.