- Wine-GitLab - list.winehq.org

Re: [PATCH v5 0/4] MR197: vkd3d-shader: Maintenance patches - approved
by Alexandre Julliard (＠julliard) May 3, 2023

May 3, 2023

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/197

1 0

Re: [PATCH v4 0/2] MR182: vkd3d-shader/hlsl: Introduce hlsl_ir_index, part 2/2 (optional). - approved
by Alexandre Julliard (＠julliard) May 3, 2023

May 3, 2023

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/182

1 0

Re: [PATCH v4 0/3] MR194: Release vkd3d 1.7.1 - approved
by Alexandre Julliard (＠julliard) May 3, 2023

May 3, 2023

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/194

1 0

[PATCH v2 0/4] MR168: hlsl: ps_1_* outputs.
by Zebediah Figura (＠zfigura) May 3, 2023

May 3, 2023

-- v2: vkd3d-shader/hlsl: Map the colour output for ps_1_* to r0. vkd3d-shader/hlsl: Rewrite the register allocator to allow allocating in multiple passes. vkd3d-shader/hlsl: Avoid leaking the allocator register map in allocate_const_registers(). vkd3d-shader/hlsl: Rename struct liveness to struct register_allocator. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/168

4 10

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

May 3, 2023

> FWIW, it's not necessarily that everything would go directly into v_s_i (clearly HLSL wouldn't), but sm1 and sm4 at least would. Contrary to what Henri said, I was actually of the impression that sm6 could deal directly with v_s_i without adding too much? Besides new opcodes and interfaces, I thought we didn't need much more than a new "SSA" register type. Well, there's the shader I/O signature and register normalisation work that Conor is currently working on, for example. I don't know if I'd qualify that as "much more", but it's essentially adapting the TPF frontend and SPIR-V backend to accommodate the DXIL frontend. It doesn't touch the representation of individual instructions much, so in that sense, sure. (Also, it ends up actually simplifying the SPIR-V backend by moving some transformations that aren't needed for DXIL to the common IR level where they're easier to do...) -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_31899

1 0

[PATCH v2 0/7] MR2719: winegstreamer: Cleanup media source streams and add synchronization.
by Rémi Bernon May 3, 2023

May 3, 2023

Mostly a refresh of https://gitlab.winehq.org/wine/wine/-/merge_requests/1278, with a bit of cleanup. More to come. -- v2: winegstreamer: Remove unnecessary media source stream states. winegstreamer: Synchronize access to the media source from callbacks. winegstreamer: Synchronize concurrent access to the media stream. winegstreamer: Synchronize concurrent access to the media source. winegstreamer: Only break cyclic references in IMFMediaSource_Shutdown. winegstreamer: Keep a IMFMediaSource pointer in the media stream. winegstreamer: Query the wg_parser stream in media_stream_create. https://gitlab.winehq.org/wine/wine/-/merge_requests/2719

5 20

Re: [PATCH v2 0/4] MR174: Consolidate the TPF and d3dbc handling code.
by Zebediah Figura (＠zfigura) May 3, 2023

May 3, 2023

> 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. Yeah, that's the primary concern. It's mostly at this point weighing that against the idea of introducing new IRs and translation passes for everything, and also writing specific assemblers and disassemblers for everything, that makes me think keeping v_s_i as complex as it is isn't actually that bad. FWIW, it's not necessarily that everything would go directly into v_s_i (clearly HLSL wouldn't), but sm1 and sm4 at least would. Contrary to what Henri said, I was actually of the impression that sm6 could deal directly with v_s_i without adding too much? Besides new opcodes and interfaces, I thought we didn't need much more than a new "SSA" register type. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_31897

1 0

[PATCH v2 0/3] MR193: vkd3d-shader/hlsl: Add support for writing RWStructuredBuffer declarations.
by Nikolay Sivov (＠nsivov) May 3, 2023

May 3, 2023

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: vkd3d-shader/hlsl: Add support for writing RWStructuredBuffer declarations. vkd3d-shader/hlsl: Add support for RWBuffer object. vkd3d-shader: Fix dcl_uav_typed_* formatting. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/193

3 5

[PATCH v6 0/5] MR2555: ntdll: Support ISOLATIONAWARE_MANIFEST_RESOURCE_ID (#18889)
by Jinoh Kang (＠iamahuman) May 3, 2023

May 3, 2023

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=18889 -- v6: ntdll: Don't hard-code DLL manifest resource ID when looking up dependency assembly. kernel32/tests: Test loading assembly manifest resource inside dependencies. ntdll: Move ACTCTX lpResourceName validation to RtlCreateActivationContext. kernel32/tests: Test setting lpResourceName to NULL for CreateActCtxW. kernel32/tests: Remove test for ACTCTX_FLAG_HMODULE_VALID with hModule = NULL case. https://gitlab.winehq.org/wine/wine/-/merge_requests/2555

5 14

[PATCH v4 0/4] MR197: vkd3d-shader: Maintenance patches
by Conor McCarthy (＠cmccarthy) May 3, 2023

May 3, 2023

-- v4: tests/d3d12: Test register relative addressing in vertex and pixel shaders. vkd3d-shader: Introduce an internal shader signature structure. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/197

2 4