May 2023 - wine-gitlab

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

03 May '23

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) 03 May '23

03 May '23

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) 03 May '23

03 May '23

-- 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) 03 May '23

03 May '23

> 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 (＠rbernon) 03 May '23

03 May '23

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

6 20

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

03 May '23

> 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) 03 May '23

03 May '23

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) 03 May '23

03 May '23

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) 03 May '23

03 May '23

-- 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

[PATCH 0/1] MR2738: po: Update Dutch translation
by Floris Renaud (＠jkfloris) 03 May '23

03 May '23

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/2738

2 1

2025

2024

2023

2022

wine-gitlab May 2023