May 2023 - wine-gitlab

[PATCH v4 0/5] MR176: hlsl: Return hlsl_ir_node pointers from instruction constructors, part 3.
by Zebediah Figura (＠zfigura) 02 May '23

02 May '23

-- v4: vkd3d-shader/hlsl: Return an hlsl_ir_node pointer from hlsl_new_resource_store(). vkd3d-shader/hlsl: Return an hlsl_ir_node pointer from hlsl_new_resource_load(). vkd3d-shader/hlsl: Return an hlsl_ir_node pointer from hlsl_new_loop(). vkd3d-shader/hlsl: Pass an hlsl_block pointer to hlsl_new_loop(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/176

4 8

[PATCH 0/1] MR187: vkd3d-shader/d3d-asm: Rename trace.c to d3d_asm.c.
by Henri Verbeet (＠hverbeet) 02 May '23

02 May '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/187

3 3

[PATCH 0/1] MR186: vkd3d-shader: Get rid of the unused vkd3d_shader_src_param_entry structure.
by Henri Verbeet (＠hverbeet) 02 May '23

02 May '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/186

3 3

[PATCH 0/3] MR194: Release vkd3d 1.7.1
by Giovanni Mascellani (＠giomasce) 02 May '23

02 May '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/194

5 5

[PATCH v2 0/9] MR2733: imm32: Tests and fixes for ImmTranslateMessage
by Rémi Bernon (＠rbernon) 02 May '23

02 May '23

-- v2: imm32: Post messages to the target window in ImmTranslateMessage. imm32: Clear vkey before calling ToAsciiEx in ImmTranslateMessage. imm32: Ignore some messages in ImmTranslateMessage. imm32: Increase the ImmTranslateMessage buffer size. imm32/tests: Test ImmTranslateMessage / ImeToAsciiEx calls. imm32/tests: Add more ImmProcessKey and ImmGetVirtualKey tests. imm32: Use INPUTCONTEXT directly in ImmRequestMessage(W|A). imm32/tests: Test cross-thread ImmRequestMessage(W|A) calls. imm32/tests: Move IME calls test helpers around. https://gitlab.winehq.org/wine/wine/-/merge_requests/2733

3 12

[PATCH v2 0/8] MR2712: winewayland.drv: part 3: Handle dynamic wl_output events
by Alexandros Frantzis (＠afrantzis) 02 May '23

02 May '23

This MR introduces the driver mechanisms to handle dynamic events from the Wayland compositor, using wl_output events as the guiding use case (i.e., we want to update the win32u display settings when the host settings change). In this design we create a dedicated thread to read and dispatch Wayland events received from the compositor. If a Wayland event handler wants some code to be run in the context of a particular HWND's thread, it can add an internal event to a custom queue we have for each (GUI enabled) thread. The ProcessEvents driver callback processes internal events from that queue. In order to wake up waiting threads we use a pipe to notify about new internal events, with the read end acting as the thread's host queue fd. This is similar to how winemac.drv works. We use the aforementioned mechanisms to queue win32u display device updates to the desktop window thread. Since there are many pieces that need to fall into place, this MR gradually reaches the final design: 1. We first introduce the dedicated read/dispatch thread and handle events (and also display device updates if in the desktop process) in that thread. 2. We ensure access to Wayland output information is thread-safe and consistent (since in step 3 we will need to access it from a different thread). 3. We finally introduce per-thread internal event queues and, if we are in the desktop process, queue the display device update to the desktop window thread internal event queue. Note that the main portion of the wl_output event code is still handled in the dedicated read/dispatch thread. -- v2: winewayland.drv: Update desktop window size on display changes. winewayland.drv: Do not process nested events. winewayland.drv: Update display devices from the desktop window thread. winewayland.drv: Introduce per-thread data. winewayland.drv: Make access to Wayland output information thread-safe. winewayland.drv: Handle dynamic Wayland output events. winewayland.drv: Read and dispatch Wayland events. winewayland.drv: Allocate process_wayland statically. https://gitlab.winehq.org/wine/wine/-/merge_requests/2712

3 14

Re: [PATCH v2 0/4] MR174: Consolidate the TPF and d3dbc handling code.
by Henri Verbeet (＠hverbeet) 02 May '23

02 May '23

> > This is what I originally thought, but I'm having slight second thoughts now. The thing is that the tradeoff is now you need a new IR for every bytecode language you have, which in our case means at least sm1, sm4, and eventually I think sm6. That's a lot of extra support code to add. Consider how much we'd need to add by putting that intermediate step into HLSL -> smX translation. The advantage of making v_s_i the IR is that you don't actually need any of that. > > You mean that you'd have just `v_s_i` and every frontend and backend deals directly with it, including for very syntactical things like assembling and disassembling? I don't feel really convinced, it seems to me that you'd have to encode su much stuff in `v_s_i` that each time you need to change something (for example to allow for a new language) the changes can have repercussions in each other language frontend or backend. Probably not for everything. E.g., I suspect the DXIL disassembler probably shouldn't go through the common IR. But fundamentally, I think that's much of the point of having a common IR. DXIL support, though not quite done yet, is perhaps a decent example there. Without going through the common IR, that would require duplicating a decent chunk of the code currently in spirv.c. There's some work required upfront to make the common IR suitable for DXIL, but ultimately the resulting code should be more maintainable. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_31740

1 0

[PATCH v5 0/7] MR181: vkd3d-shader: Normalise signatures and input/output registers to the Shader Model 6 pattern.
by Conor McCarthy (＠cmccarthy) 02 May '23

02 May '23

-- v5: vkd3d-shader: Add source information to normaliser errors and warnings. vkd3d-shader/ir: Normalise signatures and input/output registers to the Shader Model 6 pattern. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/181

3 9

[PATCH v7 0/2] MR184: vkd3d-shader/hlsl: Add support for SampleGrad() method
by Ethan Lee (＠flibitijibibo) 02 May '23

02 May '23

~~This one's marked as a draft, as there seems to be a blocker with the method parameters.~~ ~~The first commit totally works, _if_ the ddx/ddy parameters are literals - they do _not_ work when passing a variable of any kind. The test comes from tests/d3d12.c, so I'm mostly just trying to migrate that to the HLSL test suite, but it currently hits an assert before we get to the resource load (which does eventually work) and I'm not sure what's causing it:~~ ``` vkd3d-compiler: libs/vkd3d-shader/tpf.c:3190: sm4_register_from_node: Assertion `instr->reg.allocated' failed. ``` ~~Seems like it's surprised when we try to load from the constant buffer maybe?~~ Fixed! -- v7: tests: Add a basic compilation test for SampleGrad() method. vkd3d-shader/hlsl: Add support for SampleGrad() method https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/184

3 5

Re: [PATCH v2 0/4] MR174: Consolidate the TPF and d3dbc handling code.
by Giovanni Mascellani (＠giomasce) 02 May '23

02 May '23

> This is what I originally thought, but I'm having slight second thoughts now. The thing is that the tradeoff is now you need a new IR for every bytecode language you have, which in our case means at least sm1, sm4, and eventually I think sm6. That's a lot of extra support code to add. Consider how much we'd need to add by putting that intermediate step into HLSL -> smX translation. The advantage of making v_s_i the IR is that you don't actually need any of that. You mean that you'd have just `v_s_i` and every frontend and backend deals directly with it, including for very syntactical things like assembling and disassembling? I don't feel really convinced, it seems to me that you'd have to encode su much stuff in `v_s_i` that each time you need to change something (for example to allow for a new language) the changes can have repercussions in each other language frontend or backend. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_31723

1 0

2025

2024

2023

2022

wine-gitlab May 2023