March 2024 - Wine-GitLab - list.winehq.org

[PATCH v2 0/3] MR701: vkd3d-shader: Remove a token for 'precise' modifier.
by Nikolay Sivov (＠nsivov) March 12, 2024

March 12, 2024

-- v2: vkd3d-shader/fx: Handle 'single' modifier for buffers. vkd3d-shader: Parse a 'single' modifier. vkd3d-shader: Remove a token for 'precise' modifier. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/701

6 7

[PATCH v4 0/3] MR698: vkd3d-shader/ir: Introduce a better CFG structurizer, part 4.
by Giovanni Mascellani (＠giomasce) March 12, 2024

March 12, 2024

~~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. -- v4: vkd3d-shader/ir: Sort loop intervals. vkd3d-shader/ir: Generate synthetic intervals for forward edges. vkd3d-shader/ir: Compute loop as intervals of the block order. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/698

4 11

[PATCH v5 0/3] MR692: vkd3d-shader/fx: Add "child-effect" compilation option.
by Nikolay Sivov (＠nsivov) March 12, 2024

March 12, 2024

-- v5: vkd3d-shader/fx: Add support for writing shared object descriptions for fx_4_x. vkd3d-shader: Add an option to enable child effects compilation. vkd3d-shader/fx: Add initial support for writing uninitialized vertex/pixel shader objects. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/692

4 6

[PATCH v3 0/5] MR681: vkd3d-shader/dxil: TGSM part 1.
by Conor McCarthy (＠cmccarthy) March 12, 2024

March 12, 2024

-- v3: vkd3d-shader/dxil: Implement DX instruction Barrier. vkd3d-shader/spirv: Emit a trace message if TGSM alignment is ignored. vkd3d-shader/dxil: Implement structured groupshared address space global variables. vkd3d-shader/dxil: Implement raw groupshared address space global variables. vkd3d-shader/spirv: Support zero-initialisation for workgroup memory. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/681

4 7

[PATCH v2 0/2] MR5238: krnl386, mmsystem: Simulate a hardware interrupt in MMSYSTDRV_Callback3216.
by Alex Henrie (＠alexhenrie) March 12, 2024

March 12, 2024

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56260 -- v2: mmsystem: Simulate a hardware interrupt in MMSYSTDRV_Callback3216. krnl386: Add functions to simulate a hardware interrupt. https://gitlab.winehq.org/wine/wine/-/merge_requests/5238

3 5

Re: [PATCH v12 0/7] MR4449: winegstreamer: WMReader compressed output
by Alfred Agrell (＠Alcaro) March 12, 2024

March 12, 2024

On Tue Mar 12 13:47:41 2024 +0000, Yuxuan Shui wrote: > @Alcaro Thank you for the help! Yes, that certainly would explain your symptoms, and why I never saw those issues. That's why Proton has a beta period, isn't it? Sounds like an easy fix, easier than comparing media types. Code duplication certainly has drawbacks, but I don't think we can blame me or WineHQ for this one; if you fork an active codebase, you get merge conflicts, and sometimes even behavioral conflicts like this. We can't let a fork constrain upstream development, can we? The safest way to avoid such trouble is get your code upstreamed. The stream order is indeed not guaranteed; as long as the input video bytestream is the same, I'm trusting that the stream order is also the same. Maybe that's naive of me, maybe it is indeed safe. I didn't check. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_64418

1 0

Re: [PATCH v12 0/7] MR4449: winegstreamer: WMReader compressed output
by Yuxuan Shui (＠yshui) March 12, 2024

March 12, 2024

On Tue Mar 12 13:40:49 2024 +0000, Yuxuan Shui wrote: > I spotted the problem. In `init_stream`: > ```c > stream->wg_stream = wg_parser_get_stream(reader->wg_parser, > reader->stream_count - i - 1); > ``` > vs `reinit_stream`: > ```c > stream->wg_stream = wg_parser_get_stream(reader->wg_parser, i); > ``` > Though indeed the order of the streams is not guaranteed to stay the > same (as per @rbernon) (Sorry forgot to mention this is proton only) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_64413

1 0

[PATCH 0/1] MR5290: ntdll/tests: fix size passed to GetModuleFileNameW
by Marcus Meissner (＠msmeissn) March 12, 2024

March 12, 2024

Signed-Off-By: Marcus Meissner <marcus(a)jet.franken.de> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5290

2 1

Re: [PATCH v12 0/7] MR4449: winegstreamer: WMReader compressed output
by Yuxuan Shui (＠yshui) March 12, 2024

March 12, 2024

On Tue Mar 12 13:33:27 2024 +0000, Alfred Agrell wrote: > If the mismatch is just compressed/uncompressed, then that's supposed to happen. > If they are indeed switching audio/video, then yes, they probably got > rearranged, and that does indeed sound like a bug. I didn't run into any > such trouble during my testing, but that may just have been my testing > being limited. > I never checked how those Unix-side streams are created, so I'm not sure > how that part should be solved. One solution would be to check the > streams' media types, compare to the expected type, and swap if > mismatched, but I don't know if it's the best answer; there may be a > better solution somewhere deeper inside winegstreamer. I spotted the problem. In `init_stream`: ```c stream->wg_stream = wg_parser_get_stream(reader->wg_parser, reader->stream_count - i - 1); ``` vs `reinit_stream`: ```c stream->wg_stream = wg_parser_get_stream(reader->wg_parser, i); ``` Though indeed the order of the streams is not guaranteed to stay the same (as per @rbernon) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_64412

1 0

Re: [PATCH v12 0/7] MR4449: winegstreamer: WMReader compressed output
by Alfred Agrell (＠Alcaro) March 12, 2024

March 12, 2024

On Tue Mar 12 13:07:01 2024 +0000, Yuxuan Shui wrote: > Like one is audio the other is video kind of mismatch. If the mismatch is just compressed/uncompressed, then that's supposed to happen. If they are indeed switching audio/video, then yes, they probably got rearranged, and that does indeed sound like a bug. I didn't run into any such trouble during my testing, but that may just have been my testing being limited. I never checked how those Unix-side streams are created, so I'm not sure how that part should be solved. One solution would be to check the streams' media types, compare to the expected type, and swap if mismatched, but I don't know if it's the best answer; there may be a better solution somewhere deeper inside winegstreamer. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_64410

1 0