This should reflect what we actually support, while still being a superset
of what native drivers actually support.
Native driver support varies, but, as the comments document, native drivers
(at least as of windows 10) support only RGB -> RGB, YUV -> RGB, and BC -> RGB
conversions. The actual formats supported are a more limited subset than exposed
(despite that the video cards should be perfectly capable of supporting more
conversions) but erring on the side of overreporting seems safer.
--
v2: wined3d: Implement wined3d_check_device_format_conversion().
https://gitlab.winehq.org/wine/wine/-/merge_requests/5816
This MR adds a default implementation for `wglChoosePixelFormatARB` (in opengl32.dll) which will be used automatically if the driver populates the wgl_pixel_format ARB fields. Thus winex11 automatically uses this, and this MR removes the driver internal implementation.
The second part of this MR adds `WGL_ARB_pixel_format` support for winewayland (we can move this to a separate MR, but I wanted to have another implementation to better assess the behavior).
The `wglChoosePixelFormatARB` behavior is loosely modeled after the the AMD driver as discussed in https://gitlab.winehq.org/wine/wine/-/merge_requests/5388. I tried to keep things simple to begin with, and the results I am getting in various apps/games are sensible, but please try this out so we can refine further.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5933
This is part XI of cmd engine rewrite.
This serie moves the IF and FOR instruction into the new CMD_NODE structure.
I'm fully aware it's a large change (commit #1).
It touches simultaneously at several components:
- lexer is no longer trying to handle nested instructions; this is now
handled over to parser which will take care of it in a recursive
fashion
- moving the IF and FOR instructions into CMD_NODE; this impacts the
parser and the execution part
These three parts are so tightly linked that I can't figure out a simple
way to split first commit in smaller bits.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5942
--
v4: d3d11/tests: Test UpdateSubresource() for NV12 textures.
d3d11/tests: Test NV12 textures without render target.
d3d11/tests: Do not check pitches.
d3d11/tests: Check for NV12 texture support before testing them.
d3d11/tests: Check the result of compiling HLSL shaders.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5818
This is another step towards getting render states out of wined3d_state.
The idea here is similar to the "push constant buffers" used for d3d8/9 flat
constants, and reuses the same infrastructure. That is, we pack all of the
constants directly into a wined3d_buffer which is bound directly to the
wined3d_state as a normal constant buffer. For SPIR-V this buffer is placed in
the GPU, and the shader can simply access it directly, with no renderer-specific
changes needed other than to determine the buffer's location.
Currently this buffer is still stored on the CPU for GLSL, and the contents are
pulled back from the sysmem resource pointer, instead of being pulled from
state->render_states.
Eventually, at least for Vulkan, the idea will be to write a FFP replacement
shader which takes structured data (which, given the constraints of SPIR-V, is
broadly necessary; we cannot simply upload individual named uniforms as we can
with GLSL). In fact this will take the form of an HLSL shader compiled to Shader
Model 2 bytecode. This allows us to, once again, reuse pretty much all of the
existing infrastructure and avoid writing more backend-specific code, and has
the effect that this FFP replacement works not only with SPIR-V but also with
GLSL, allowing us to eventually remove the existing GLSL FFP pipeline, and
enabling me to develop the HLSL FFP pipeline mainly using the GL renderer [which
is useful since the Vulkan renderer is still missing a few other features].
The full branch is available at [1], and passes all tests when using the GL
renderer.
[1] https://gitlab.winehq.org/zfigura/wine/-/tree/himavant8
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5815
I'm currently, very unsuccessfully, tracking down a crash on the unix side that only happens on Gitlab, and although I'm still unable to reproduce it, it then would be useful to have gdb to attach on segfault when I will.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5367