On Tue Oct 31 01:56:29 2023 +0000, Henri Verbeet wrote:
I'm probably missing a decent chunk of the discussion at this point, but where are we going with this, and why did we want that again?
I am not good with big pictures, but I think our main objective is to make the shader_runner expressive enough to support SM1 and SM6 profile tests.
The spontaneous order in which seems we will achieve this is: 1. @cmccarthy patches to test compilation (not execution yet) of tests with SM6 profiles, using DXC. Which are already upstreamed. 2. My patches to test compilation of SM1 tests (not execution yet) with SM1 profiles, using vkd3d. This series belongs to these. I am trying to get to this point to upload proper tests for the the patches to merge separate samplers in SM1. 3. @zfigura patches to actually run SM1 tests using vkd3d.
Much discussion has been towards how to achieve this expressive capability without making the shader_runner or the tests too cumbersome. This is a difficult problem because we not only have to specify which shader models each test must be run with, but also for which ones we are in `todo` state, or on which one we expect `fail` or `notimpl` (we are calling these "qualifiers"). We have to intersect these [require] "shader ranges" with the "shader ranges" that each runner is capable of running.
I have been updating this series as the concept of "shader ranges" for the shader_runner has been evolving, but after more discussion we have agreed with @gio and @zfigura to follow @giomasce's [proposal](https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/418#note_49736) of address the shader models individually, on which I am working.
I also have patches queued to improve the expressivity of the __qualifiers__.