March 2024 - wine-gitlab

[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

Re: [PATCH v6 0/4] MR537: vkd3d-shader/ir: Expand index range write masks to cover all element masks.
by Giovanni Mascellani (＠giomasce) 08 Mar '24

08 Mar '24

Test `test_hull_shader_punned_array()` currently emits this validation error: ``` VUID-RuntimeSpirv-OpEntryPoint-08743(ERROR / SPEC): msgNum: -1986897773 - Validation Error: [ VUID-RuntimeSpirv-OpEntryPoint-08743 ] Object 0: handle = 0x270000000027, type = VK_OBJECT_TYPE_SHADER_MODULE; Object 1: handle = 0x280000000028, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0x89925893 | vkCreateGraphicsPipelines(): pCreateInfos[0] (SPIR-V Interface) VK_SHADER_STAGE_TESSELLATION_CONTROL_BIT declared input at Location 2 Component 3 but it is not an Output declared in VK_SHADER_STAGE_VERTEX_BIT. The Vulkan spec states: Any user-defined variables shared between the OpEntryPoint of two shader stages, and declared with Input as its Storage Class for the subsequent shader stage, must have all Location slots and Component words declared in the preceding shader stage's OpEntryPoint with Output as the Storage Class (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.ht…) ``` It might or might not be related to this MR, I haven't debugged yet. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/537#note_64015

1 0

[PATCH v2 0/7] MR698: Draft: vkd3d-shader/ir: Introduce a better CFG structurizer, part 4.
by Giovanni Mascellani (＠giomasce) 08 Mar '24

08 Mar '24

This applies on top of !672, the last three commits belong here. Here we compute additional "synthetic" loops that will be used to implement non-trivial forward edges using (possibly conditional) `break` instructions. -- v2: vkd3d-shader/ir: Sort loop intervals. vkd3d-shader/ir: Generate synthetic intervals for forward edges. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/698

2 7

[PATCH 0/2] MR5263: win32u: Only send mouse input in ReleaseCapture() when a window is captured.
by Zhiyi Zhang (＠zhiyi) 08 Mar '24

08 Mar '24

Fix a regression from "bb496ea8 - server: Always queue mouse messages delivered to another window." Fix ETHER VAPOR Remaster (214570) launches to black screen when the cursor is in the game window. The game calls ReleaseCapture() when handling WM_MOUSEMOVE. After bb496ea8, WM_MOUSEMOVE is always queued because the message window is NULL. So ReleaseCapture() ends up queuing another WM_MOUSEMOVE. So the game ends up handling infinite WM_MOUSEMOVE messages at startup and is not able to do anything. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5263

4 5

[PATCH v3 0/4] MR5220: win32u: Move vulkan d3dkmt implementation out of winex11.
by Rémi Bernon (＠rbernon) 08 Mar '24

08 Mar '24

-- v3: win32u: Move D3DKMT vulkan implementation out of winex11. win32u: Open adapters in NtGdiDdDDIEnumAdapters2 outside of the display devices lock. win32u: Move D3DKMTSetVidPnSourceOwner / D3DKMTCheckVidPnExclusiveOwnership out of winex11. win32u: Move D3DKMT functions to a new d3dkmt.c source. https://gitlab.winehq.org/wine/wine/-/merge_requests/5220

3 7

2025

2024

2023

2022

wine-gitlab March 2024