February 2024 - Wine-GitLab

[PATCH v2 0/4] MR645: vkd3d-shader/dxil: Implement DX intrinsics AtomicBinOp and AtomicCompareExchange.
by Conor McCarthy (＠cmccarthy) Feb. 14, 2024

Feb. 14, 2024

-- v2: vkd3d-shader/dxil: Implement DX intrinsic AtomicCompareExchange. vkd3d-shader/dxil: Implement DX intrinsic AtomicBinOp. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/645

3 9

Re: [PATCH v7 0/3] MR3105: Add a few additional nullchecks (Coverity) - approved
by Huw Davies (＠huw) Feb. 14, 2024

Feb. 14, 2024

This merge request was approved by Huw Davies. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3105

1 0

[PATCH 0/1] MR650: tests/shader-runner: Add a 64-bit switch test.
by Conor McCarthy (＠cmccarthy) Feb. 14, 2024

Feb. 14, 2024

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

4 3

[PATCH 0/1] MR649: vkd3d-shader: Raise the instruction parameter allocation size if necessary.
by Conor McCarthy (＠cmccarthy) Feb. 14, 2024

Feb. 14, 2024

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

4 3

[PATCH 0/16] MR647: vkd3d-shader/dxil: Check for src param allocation failure.
by Conor McCarthy (＠cmccarthy) Feb. 14, 2024

Feb. 14, 2024

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

4 18

[PATCH v2 0/3] MR643: vkd3d-shader/dxil: Implement DX intrinsics Sample and SampleGrad.
by Conor McCarthy (＠cmccarthy) Feb. 14, 2024

Feb. 14, 2024

-- v2: vkd3d-shader/dxil: Implement DX intrinsic SampleGrad. vkd3d-shader/dxil: Implement DX intrinsic Sample. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/643

4 5

[PATCH v5 0/4] MR627: vkd3d: Implement ID3D12Resource2.
by Conor McCarthy (＠cmccarthy) Feb. 14, 2024

Feb. 14, 2024

-- v5: vkd3d: Implement ID3D12Resource2. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/627

3 5

Re: [PATCH v28 0/3] MR4982: dmime: load MIDI files
by Yuxuan Shui (＠yshui) Feb. 14, 2024

Feb. 14, 2024

On Tue Feb 13 16:54:26 2024 +0000, Rémi Bernon wrote: > Like we discussed I now think this should be implemented more like > native. As far as I can tell it uses the existing track classes and > parses MIDI files into them, dispatching the events on each track and > creating new tracks if needed depending on the event types. > This could actually make the implementation simpler as many track > classes are already partially implemented, so it'd just be a matter of > filling them with the parsed MIDI events. @rbernon i understand, and i already agreed with you. this MR has been cut back to only include parsing of MIDI file headers -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4982#note_61132

1 0

[PATCH 0/4] MR4791: gdi32,win32u,winex11: Implement D3DKMTEnumAdapters2.
by Krzysztof Bogacki (＠Saancreed) Feb. 14, 2024

Feb. 14, 2024

This implements most of `D3DKMTEnumAdapters2` function, which is [indirectly used by all games using NVIDIA Streamline SDK](https://github.com/NVIDIAGameWorks/Streamline/blob/7ac42e47c7dd55b5b6d…. Having it (and [one another D3DKMT function](https://github.com/NVIDIAGameWorks/Streamline/blob/7ac42e47c7dd55… but one thing at a time) working is a requirement to enable some interesting features like DLFG (also known as DLSS-G / DLSS Frame Generation). Although currently not supported by NVIDIA on Unix systems, the lack of these functions also prevents [some game modifications that hijack DLSS-G](https://github.com/Nukem9/dlssg-to-fsr3) from working altogether because the adapter check still has to be performed. The way I chose to tackle this was adding a new GDI driver function which winex11 then implements. This mirrors how `D3DKMTOpenAdapterFromLuid` is implemented, but a not-so-short conversation I had with Paul Gofman made me realize that there could be a better way to do this by tapping into win32u's adapter cache. More on that closer to the end, first I'll explain my initial idea. The handle assignment is quite tricky; because this is done in win32u, we need to prepare as many handles as the number of elements in the array we were passed. However, this array can be much larger than the actual number of GPUs in the system (Windows 10 machine I ran some tests on always responded with 32 `NumAdapters` when given `NULL` in `pAdapters` even though there were just 2 adapters available). I chose to resolve this by allocating that many handles, then calling GDI driver function while still holding the mutex, then freeing unused handles from the end of the list. Some possible alternatives would be: * Not holding the mutex while calling GDI driver function. We would still allocate more handles than needed but other functions would not be blocked while winex11 is doing its thing. We would then acquire the mutex again to free unused handles, which would require us to search for them first because it would no longer be guaranteed that they are at the end of the list. * Calling the GDI driver function more than once, the first time to actually enumerate GPUs and the second time to give their handles GDI driver to save them, which would complicate the API contract between win32u and GDI driver quite a bit. * Pass an additional parameter to let GDI driver allocate handles itself. It could be something as simple as pointer to the next handle variable, or something as complicated as an allocator function than can do anything win32 needs it to do (plus maybe a deallocator function to handle errors). But I suppose it would still require the mutex to be held for the entire call. * … or something else I didn't think of. There are two more members returned in each adapter info struct, `NumOfSources` and `bPrecisePresentRegionsPreferred`. I'm not exactly sure how am I supposed to handle them so for now they will always be left zeroed. VidPN and related stuff are just too arcane for me, sorry 😅 However, Paul suggested that I don't actually need to add a new GDI driver function to implement this. If I considered win32u's adapter list as maintained in `sysparams.c` to be the source of truth here, I could avoid calling into GDI driver and just perform the enumeration within win32u. But with how other D3DKMT functions are currently implemented, this will almost surely cause issues when interacting with some of them; e.g. handles returned by `EnumAdapters2` wouldn't be usable with `D3DKMTQueryVideoMemoryInfo` because that function _does_ forward most of the heavy lifting to be done by the GDI driver and winex11 would be unaware of what the given handle represents, hence unable to query appropriate `VkPhysicalDevice`. (In the short term this could probably be avoided by calling `D3DKMTOpenAdapterFromLuid` for each enumerated LUID but this in turn relies on adapters actually having valid LUIDs assigned. On my current machine, Intel/Nvidia dual GPU laptop running Plasma Wayland, mainline Wine without some patches pulled from Proton seems to have… issues doing this properly…) On the other hand, if everything in D3DKMT family of functions already went through win32u caches, this would have been much simpler. _Probably._ But because it does not, I feel like I should ask: why was it done like that? If there was a specific reason for avoiding win32u caches, what would be the correct way of implementing `EnumAdapters2` then? Following the way of `OpenAdapterFromLuid` and mapping UUIDs to LUIDs manually via the registry (my first/existing version, which also makes this fully reliant on Vulkan) or rewriting all this to go through win32u adapter cache? If the latter, then shouldn't existing D3DKMT functions perhaps be rewritten to use the cache as well and avoid calling GDI driver/Vulkan? I'm open to suggestions so please let me know if you have any. (I'm aware Wine is currently in code freeze, but I wanted to send this to gather some early feedback, I'm fine with waiting a few weeks before this becomes eligible for merging.) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4791

6 12

[PATCH v5 0/1] MR4934: Unit tests for GetAdaptersAddresses put into individual functions
by John H. Freeman (＠tingling0072) Feb. 14, 2024

Feb. 14, 2024

added invocation to test list -- v5: Split out test for ERROR_INVALID_PARAMETER return https://gitlab.winehq.org/wine/wine/-/merge_requests/4934

3 4