We want `.shader_test` file to only have at most one `[require]` directive, and have it at the top of the file, so that we don't have all the problems connected with changing the requirements mid-file. Files that require testing under different requirements will have to be split.
Yep, I agree that this is a reasonable way of splitting the tests, even if it costs some redundancy. But I think that that change should be a separate MR.
This `[require]` directive should list all the shader models that make sense for whatever is tested, so that there is no need for guesswork (in the form of the current "pick the minimum supported SM" rule) by the runner. For the SMs not supported by the runner, there is nothing to test. This is considered a compromise between running at all possible shader models (expensive) and resorting to complicated logics to pick the shader models that make sense by intersecting what the shader test supports, what the shader runner supports and using some heuristic.
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.
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, 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.