March 2024 - wine-gitlab

[PATCH v10 0/1] MR673: tests/shader-runner: Add sampler comparison tests.
by Conor McCarthy (＠cmccarthy) 08 Mar '24

08 Mar '24

-- v10: tests/shader-runner: Add sampler comparison tests. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/673

4 3

[PATCH v6 0/4] MR582: vkd3d-dxbc: Add options to fix a DXBC shader checksum.
by Giovanni Mascellani (＠giomasce) 08 Mar '24

08 Mar '24

-- v6: vkd3d-dxbc: Add an option to choose the output filename. vkd3d-dxbc: Add an option to re-emit the shader with the correct checksum. vkd3d-dxbc: Add an option to ignore checksum. vkd3d-shader/dxbc: Add flag to ignore the DXBC checksum. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/582

3 5

[PATCH 0/3] MR5264: winewayland.drv: part 13.2: More OpenGL functionality
by Alexandros Frantzis (＠afrantzis) 08 Mar '24

08 Mar '24

This MR adds support for some more OpenGL functionality: * wglCreateContextAttribsARB * wglShareLists * wgl(Get)SwapIntervalEXT I originally intended to also include a fix for the translucency issue seen in some compositors, by using EGL_EXT_present_opaque. However, I'll hold off for now since I am seeing some issues with certain hardware and pixel formats when using this extension. Initial investigation indicates it is a problem in Mesa. For anyone who is affected by the translucency issue and wants to try out the patch in their local build anyway, it is at: https://gitlab.winehq.org/afrantzis/wine/-/commit/0685d1d2cfc126e2bb546fe2c… -- A question for the upcoming work: In the next OpenGL part I would like to focus on `WGL_ARB_pixel_format`. I was thinking that if a driver implements `wglGetPixelFormatAttribivARB` then it would be possible, in theory at least, to have a default implementation of `wglChoosePixelFormatARB` (and `wglGetPixelFormatAttribfvARB`) in `opengl32`. I am tempted to do this, instead of adding one more driver specific full implementation, although I am not yet sure if there any driver specific considerations or behaviors that would pose issues with such approach. Thoughts? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5264

3 10

Re: [PATCH v7 0/1] MR3422: ddraw tests for Pick and GetPickRecords
by Stefan Dösinger (＠stefan) 08 Mar '24

08 Mar '24

On Fri Mar 8 17:52:04 2024 +0000, Stefan Dösinger wrote: > So on my Radeon 9000 (r250), Windows XP, this produces no pick results > for the HW device: > ``` > ddraw1.c:15913: Driver string: "ati2dvag.dll" > ddraw1.c:15914: Description string: "Mobility Radeon 9000" > ddraw1.c:15915: Driver version 0.0.0.0 > ddraw1.c:15638: Test failed: run {84e63de0-46aa-11cf-816f-0000c020156e} > ddraw1.c:15689: Test failed: Got incorrect number of pick records > (expected 1): 0. > ddraw1.c:15696: Test failed: Got incorrect number of pick records > (expected 3): 0. > ddraw1.c:15728: Test failed: Got incorrect number of pick records > (expected 1): 0. > ddraw1.c:15737: Test failed: Got incorrect number of pick records > (expected 1): 0. > ddraw1.c:15765: Test failed: Got an unexpected ratio of pick > hits/misses: 0/256. > ddraw1.c:15805: Test failed: Got incorrect number of pick records > (expected 1): 0. > ddraw1.c:15817: Test failed: Got incorrect number of pick records > (expected 3): 0. > ddraw1.c:15829: Test failed: Got incorrect number of pick records > (expected 1): 0. > ddraw1.c:15838: Test failed: Got incorrect number of pick records > (expected 1): 0. > ddraw1.c:15866: Test failed: Got an unexpected ratio of pick > hits/misses: 0/256. > ddraw1.c:15638: Test failed: run {a4665c60-2673-11cf-a31a-00aa00b93356} > 08f4:ddraw1: 204 tests executed (0 marked as todo, 0 as flaky, 12 > failures), 0 skipped. > ``` > I'll try to figure out why and see if I can test the game that inspired > the original author to implement this method to see if it works. > The RGB device works as expected. The test passes on the HW device of my way newer Radeon Polaris card on Windows 11. As of now I am unsuccessful in getting my Radeon 9000 from 2002 to produce any pick results. On a quick test run it seems Lego Island is happy with setting *count = 0 in IDirect3DDevice::GetPickRecords. That prevents it from trying to essentially malloc a random amount of memory. But I am not entirely certain, the menu of this game is confusing. I was (intellectually) unable to start a game even on Windows... I am downloading FIGHTING to see if it works on my old machine and to see if it uses a HW device or just the RGB device. Judging by the screenshots it might just software render. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3422#note_64027

1 0

[PATCH 0/1] MR5265: server: Remove desktop from their winstation list before looking for another input desktop.
by Rémi Bernon (＠rbernon) 08 Mar '24

08 Mar '24

This looks like a mistake and it could explain and hopefully fix https://bugs.winehq.org/show_bug.cgi?id=56406. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5265

2 1

Re: [PATCH v7 0/1] MR3422: ddraw tests for Pick and GetPickRecords
by Stefan Dösinger (＠stefan) 08 Mar '24

08 Mar '24

So on my Radeon 9000 (r250), Windows XP, this produces no pick results for the HW device: ``` ddraw1.c:15913: Driver string: "ati2dvag.dll" ddraw1.c:15914: Description string: "Mobility Radeon 9000" ddraw1.c:15915: Driver version 0.0.0.0 ddraw1.c:15638: Test failed: run {84e63de0-46aa-11cf-816f-0000c020156e} ddraw1.c:15689: Test failed: Got incorrect number of pick records (expected 1): 0. ddraw1.c:15696: Test failed: Got incorrect number of pick records (expected 3): 0. ddraw1.c:15728: Test failed: Got incorrect number of pick records (expected 1): 0. ddraw1.c:15737: Test failed: Got incorrect number of pick records (expected 1): 0. ddraw1.c:15765: Test failed: Got an unexpected ratio of pick hits/misses: 0/256. ddraw1.c:15805: Test failed: Got incorrect number of pick records (expected 1): 0. ddraw1.c:15817: Test failed: Got incorrect number of pick records (expected 3): 0. ddraw1.c:15829: Test failed: Got incorrect number of pick records (expected 1): 0. ddraw1.c:15838: Test failed: Got incorrect number of pick records (expected 1): 0. ddraw1.c:15866: Test failed: Got an unexpected ratio of pick hits/misses: 0/256. ddraw1.c:15638: Test failed: run {a4665c60-2673-11cf-a31a-00aa00b93356} 08f4:ddraw1: 204 tests executed (0 marked as todo, 0 as flaky, 12 failures), 0 skipped. ``` I'll try to figure out why and see if I can test the game that inspired the original author to implement this method to see if it works. The RGB device works as expected. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3422#note_64021

1 0

Re: [PATCH v7 0/1] MR3422: ddraw tests for Pick and GetPickRecords
by Stefan Dösinger (＠stefan) 08 Mar '24

08 Mar '24

On Fri Mar 8 15:47:14 2024 +0000, Jeffrey Smith wrote: > I checked this, and you are correct. I will improve the test to cover > this as well. Looks good. I think it is awkward that it returns D3D_OK regardless of the insufficient buffer, but that's Microsoft's choice, not yours... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3422#note_64019

1 0

[PATCH v3 0/6] MR694: vkd3d-shader/hlsl: Improve SM1 support for non-float operations, part 2.
by Francisco Casas (＠fcasas) 08 Mar '24

08 Mar '24

Patches with tests and other miscellaneous changes required before the remaining features in my [sm1_logic](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/sm1_logic) branch. Includes some rebased spirv.c patches by Zeb. -- v3: vkd3d-shader/spirv: Implement SLT and SGE. vkd3d-shader/spirv: Implement CMP. tests: Check that -0.0f is not less than 0.0f. tests: Test comparison and logic operators on SM1 vertex shaders. vkd3d-shader/hlsl: Cast slt before multiplying on ternary operator. tests/shader-runner: Pass uniforms to vertex shaders in d3d9 and d3d11. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/694

3 6

[PATCH v2 0/6] MR694: vkd3d-shader/hlsl: Improve SM1 support for non-float operations, part 2.
by Francisco Casas (＠fcasas) 08 Mar '24

08 Mar '24

Patches with tests and other miscellaneous changes required before the remaining features in my [sm1_logic](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/sm1_logic) branch. Includes some rebased spirv.c patches by Zeb. -- v2: vkd3d-shader/spirv: Implement SLT and SGE. vkd3d-shader/spirv: Implement CMP. tests: Check that -0.0f is not less than 0.0f. tests: Test comparison and logic operators on SM1 vertex shaders. vkd3d-shader/hlsl: Cast slt before multiplying on ternary operator. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/694

5 14

Re: [PATCH v7 0/1] MR3422: ddraw tests for Pick and GetPickRecords
by Stefan Dösinger (＠stefan) 08 Mar '24

08 Mar '24

On Fri Mar 8 15:33:07 2024 +0000, Jeffrey Smith wrote: > Yes, depth-clipped. > If I'm understanding your last statement properly, it doesn't seem > right. Two triangles could share one or two vertices and still be > clipped independently. Further, several of the quads in this test have > all vertices outside of [0,1] depth range, yet the portions passing > through that depth range do result in successful picks. What I mean with the last statement is that clipping is not done by the actual drawing step, but by the preceding "process vertices" step. It looks like D3DPROCESSVERTICES_TRANSFORM performs clipping and presumably D3DPROCESSVERTICES_TRANSFORMLIGHT does as well, whereas D3DPROCESSVERTICES_COPY just blindly copies, as the name implies. If you then draw the blindly copied triangles they result in picks. In d3dexecutebuffer we can't look at the vertex processing output. IDirect3DVertexBuffer7::ProcessVertices does allow you to look at the intermediary output, and I remember trying to make sense of its clipping operation as one of my first acts of Wine development back in 2005 and couldn't figure it out. I'm not asking you to try, I was merely commenting that clipping being part of vertex processing, not drawing, makes sense :-) . A clipped vertex still ended up in the destination vertex buffer, and it has to, because otherwise the draw parameters wouldn't match up (you process 10 triangles / 30 vertices, draw 10 triangles, but 5 of those triangles got clipped? What now?). Otoh math dictates that a clipped triangle might end up as a quad, e.g.: -------------------- | | | 1.........A.........3 | . | .... | . ..B.. | . .... | | 2... | | | | | -------------------- If that little ASCII art makes any sense. The triangle 1-2-3 turns into a quad 1-2-B-A. So somehow this needs to be handled, and I have no clue how. The ProcessVertices docs talk about an "internal buffer" storing "clipping codes". I don't think we really care unless we find an application that cares. Half Life 1 uses ProcessVertices in its d3d renderer (which has been removed long ago from the Steam version of the game), and it requests clipping, but it is just happy if we don't clip in ProcessVertices and let GL figure it out during drawing. I assume the reason why you get pick results outside the x/y limits of the framebuffer is the guard band: https://learn.microsoft.com/en-us/windows-hardware/drivers/display/guard-ba… . Long story short, actual geometry clipping is annoying, so GPUs pretend the framebuffer is much larger, don't modify geometry if possible and discard fragments outside the framebuffer later. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3422#note_64016

1 0

2025

2024

2023

2022

wine-gitlab March 2024