March 2024 - wine-gitlab

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

[PATCH 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. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/698

2 8

[PATCH v6 0/1] MR5186: win32u: fix NtGdiExtCreateRegion implementation
by Bartosz Kosiorek (＠gang65) 08 Mar '24

08 Mar '24

-- v6: win32u: fix NtGdiExtCreateRegion implementation https://gitlab.winehq.org/wine/wine/-/merge_requests/5186

4 4

Re: [PATCH v15 0/6] MR553: vkd3d-shader/d3d-asm: Dump the input and output signatures.
by Giovanni Mascellani (＠giomasce) 08 Mar '24

08 Mar '24

On Fri Mar 8 09:47:03 2024 +0000, Giovanni Mascellani wrote: > Yeah, right. Even for SM6 the current code is likely to produce bad > results, because AFAIU many signature elements can be merged in a single > one using `register_count`. I think the appropriate action right now is > to emit the signature only for SM4-5, and leave the rest to the future > if the need will arise. I will submit a MR for that. Mmh, I'm probably confused about SM6. At least for the moment these metadata are meant to represent whatever is stored in the DXBC container, so it shouldn't change anything with SM6. I'll just disable for SM1-3. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/553#note_63977

1 0

Re: [PATCH v15 0/6] MR553: vkd3d-shader/d3d-asm: Dump the input and output signatures.
by Giovanni Mascellani (＠giomasce) 08 Mar '24

08 Mar '24

On Fri Mar 8 09:47:03 2024 +0000, Henri Verbeet wrote: > Should we output input/output signatures for d3dbc shaders? Currently we > do, and there's something to be said for that, but it does complicate > things in a couple of ways: > - We wouldn't be able to assemble such signatures in any meaningful > way for d3dbc targets. I.e., the assembler would largely just have to > ignore them. > - The register names are slightly different. E.g. ps_2_0 has t# > texture coordinate inputs and oC# colour outputs. Yeah, right. Even for SM6 the current code is likely to produce bad results, because AFAIU many signature elements can be merged in a single one using `register_count`. I think the appropriate action right now is to emit the signature only for SM4-5, and leave the rest to the future if the need will arise. I will submit a MR for that. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/553#note_63974

1 0

[PATCH v5 0/1] MR5186: win32u: fix NtGdiExtCreateRegion implementation
by Bartosz Kosiorek (＠gang65) 08 Mar '24

08 Mar '24

-- v5: win32u: fix NtGdiExtCreateRegion implementation https://gitlab.winehq.org/wine/wine/-/merge_requests/5186

3 2

2025

2024

2023

2022

wine-gitlab March 2024