Yes. Still, @zfigura pointed out that we may still want to make the distinction between the minimum_shader_model and the selected_shader_model. If I understand correctly, this refers to patch 2/4. But I think we can reevaluate if we want to keep it once I send a new version of this MR, because they will be the same, at least in our use cases, once we start hardcoding the shader model ranges.
I think I am a bit confused by the fact that we have a few of different `{minimum,maxiumum}_shader_model` around. In 3/4, in particular, there are a pair of them given by the `[require]` directives and another pair given by the runner.
The proposal I am framing is that the `[require]` directive shouldn't really specify a range, but a list of specific SMs, like this: ``` [require] shader model 2.0 shader model 4.0 shader model 5.1 shader model 6.0 ```
The problem with expressing a range, like we do now, is that you either then test only one of the SMs in the range (potentially skipping others that still make sense to test, like if, for instance, there is some behavior difference betweem 4.0, 5.0 and 5.1) or you test all of them, which might be a waste of time. Here, instead, the shader test author can choose all the alternatives that make sense.
Of course, of that list, only the SMs that belong to the range supported by the runner will be tested.
Hardcoding the shader model ranges is something that we talked about and it is not on this list, but I think it simply consists on making each runner run one test in the SM 2 to SM 3 range, one in the SM 4 to SM 5.1 range, and the SM 6,
Yes, something like that. But with the option to choose, for instance, more than one between 4.0 and 5.1 if that test touches stuff that changed between those.
so runners would either support or not running the whole range and never, start supporting it from the middle, which simplifies some of the logic.
I'm not sure I understand what you mean here.