This is obviously questionable, as it requires reaching into Wine internals in
tests (beyond simply detecting whether Wine is in use).
However, we are at a point where, for d3d10 and above, the Vulkan renderer works
well enough in general to see real use [in fact, in my experience it usually
works better than the GL renderer], and at this point I think avoiding
regressions is quite important. It is currently difficult to run tests with it
when the results contain so much noise, and I think we need to solve this
problem, by actually marking which tests work on each backend.
We could in theory expose the renderer through some adapter string, but I
believe in the past applications have been sensitive about the contents of
adapter strings.
Fixing either renderer to reach and maintain parity is not feasible. The GL
renderer is not going away, but regrettably GL as an API is abandoned by
Khronos, and important features we need in order to implement some Direct3D
features will probably never be introduced into GL. Moreover, the amount of
effort that would be required to reach parity is not small, and itself would all
need to be verified manually.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3232