Personally, I'm not a fan of the switch/case style of tests. My preference would be to either just explicitly write out the tests, or to encode them using the `tests[]` construction we use in a couple of other tests.
Do you have any recommendations on what to put in a `tests[]` table? I feel like I'd end up with this, which doesn't make it super obvious how the values get used in the test.
Mostly what Zeb said; there doesn't seem all that much commonality between these. Generally, I think we should value clarity over compactness for the tests, particularly if we'd like people other than the original author to work on them.
I don't mind the switch in tests on principle,
I'm sure there are exceptions, but generally I find the "switch on loop index" construct not all that much more readable than just using "goto"...
I don't think the comment is terribly clear, but it sounds like we're getting fixed-function with the GL backend, and things just happen to work with the Vulkan backend because we don't yet have a fixed-function implementation there.
As in we're getting GL's emulation of d3d ffp, or we're hitting GL ffp? [I took an apitrace](https://gitlab.winehq.org/wine/wine/uploads/f29fa0f24cb38f3f2600183eddd28201...) and if you look at call 233640, it is using a program with a VS and no FS, so I don't think we're hitting ffp emulation. As for whether we're hitting GL's ffp path, I don't think so but I don't really know GL that well.
Well, either. Looking at the actual code in set_glsl_shader_program() though, it looks like we'd end up with "ps_id" being 0 when we have a sm4+ vertex shader, and that seems consistent with the apitrace. In a compatibility context, that would get us GL fixed-function, while in a pure core context we'd probably get a GL error. I imagine we instead get validation layer errors from this with the Vulkan backend?