The specific syntax isn't terribly important at this point, but the parser would essentially just unroll the loop in that case.
It's not the syntax I'm trying to ask about, it's the implementation.
I'm not sure the implementation really is the interesting part, but see [the attached patch](/uploads/baab2c3a5fbb254e3de6d345579de56f/shader_runner_loops.diff) for a potential proof of concept. It takes some shortcuts, but I think it illustrates the basic concept that I had in mind well enough.
Having things like the following makes sense to me:
run_tests_opengl_glsl(); run_tests_opengl_spirv(); run_tests_vulkan_spirv();and I can see the argument (if it's indeed being made) that anything else should be organized the same way. For things that matter to the runner (i.e. most of the items in your list) I think that's right, but I don't see that making sense for something that needs to be controlled by the input file.
Actually, I'd even argue for just: ``` run_tests_opengl(); run_tests_vulkan(); ... ``` I.e., handling variants like GLSL/SPIR-V internally in the runners.
The broader, more important point though is that most of what's in this MR just shouldn't be needed for d3dbc support.
No, it's not, and we could just take something like [1] which I wrote ages ago. But I think that more individual shader levels is something we're going to need sooner rather than later. I already have tests for sm1 semantics that would like it.
[1], https://gitlab.winehq.org/zfigura/vkd3d/-/commit/f0a92809bb43eb0761985b4db3a...
I think the referenced commit is largely what I had in mind as far as d3dbc support is concerned, yes.