- wine-gitlab - winehq.org

[PATCH v8 0/6] MR642: vkd3d-shader/dxil: Implement DX intrinsics BufferStore and RawBufferStore.
by Conor McCarthy (＠cmccarthy) 20 Feb '24

20 Feb '24

-- v8: vkd3d-shader/dxil: Implement DX intrinsic RawBufferStore. vkd3d-shader/dxil: Handle raw and structured buffers in sm6_parser_emit_dx_buffer_store(). vkd3d-shader/dxil: Implement DX intrinsic BufferStore. tests/shader-runner: Add a test for a signed int structured buffer UAV. tests/shader-runner: Add a test for a signed int typed buffer UAV. tests/shader-runner: Support structured buffer UAVs. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/642

2 6

[PATCH 0/5] MR5106: wined3d/arb: Move FFP constants to arbfp_apply_draw_state().
by Zebediah Figura (＠zfigura) 20 Feb '24

20 Feb '24

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

3 6

[PATCH v19 0/8] MR3103: server: Create and use a desktop shared mapping for GetCursorPos.
by Rémi Bernon (＠rbernon) 20 Feb '24

20 Feb '24

First part of Proton shared memory series. The full branch can be seen at https://gitlab.winehq.org/rbernon/wine/-/commits/mr/shared-memories. -- v19: win32u: Use the desktop shared data for NtUserSetCursorPos. server: Move the last cursor time to the desktop session object. server: Move the cursor position to the desktop session object. win32u: Open desktop shared objects from session mapping. include: Add ReadNoFence64 inline helpers. server: Allocate shared session object for desktops. win32u: Open the global session shared mapping. server: Create a global session shared mapping. https://gitlab.winehq.org/wine/wine/-/merge_requests/3103

3 17

[PATCH v3 0/2] MR5112: DBI substreams in PDB files.
by eric pouech (＠epo) 20 Feb '24

20 Feb '24

We used to expect a fixed number of DBI substreams (the expected number depended on the DBI header version). Recent MSVC generate a different number as we expected. Implement a more flexible scheme where we allow any number of streams. This lets these recent PDB files to be properly displayed by winedump, and loaded/parsed by dbghelp. -- v3: dbghelp: Don't expected a fixed number of substreams in DBI header (PDB). winedump: Don't expect a fixed number of substreams in DBI header (PDB). https://gitlab.winehq.org/wine/wine/-/merge_requests/5112

2 3

Re: [PATCH v4 0/1] MR632: vkd3d: Implement d3d12_command_list_OMSetDepthBounds()
by Henri Verbeet (＠hverbeet) 20 Feb '24

20 Feb '24

> > We probably should, but I think we're also allowed to just clamp to \[0, 1\]. It's not immediately clear to me whether a corresponding caps bit exists for this in d3d12. > > If, as it seems, there isn't one, then I think `DepthBoundsTestSupported` should be intended as advertising support for an unrestricted range, so shouldn't be set unless we're able to uphold to that promise (i.e., `VK_EXT_depth_range_unrestricted` is available). Why is clamping to \[0, 1\] a good solution? The application is likely to misrender if we change the requested parameters under its feet. I'm mostly going by the line "The runtime will not clamp or validate the input, but implementations may clamp to the range [0,1] if necessary." from https://microsoft.github.io/DirectX-Specs/d3d/DepthBoundsTest.html#detailed…. That seems slightly ambiguous though; it's not immediately clear to me whether "necessary" there refers to e.g. limitations of the depth format in use, or limitations of the GPU more generally. (I.e., the question seems somewhat moot for depth formats like DXGI_FORMAT_D24_UNORM_S8_UINT that can't represent values outside [0,1].) The "Testing" section doesn't appear to address that question either. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/632#note_62025

1 0

Re: [PATCH v2 0/1] MR5046: advapi32: CryptEnumProviders doesn't return pdwProvType when szProvName is NULL.
by Hans Leidekker (＠hans) 20 Feb '24

20 Feb '24

Thanks for the patch, I have added some comments. Please get rid of the merge commit and rebase on current master. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5046#note_62023

1 0

Re: [PATCH v2 0/1] MR5046: advapi32: CryptEnumProviders doesn't return pdwProvType when szProvName is NULL.
by Hans Leidekker (＠hans) 20 Feb '24

20 Feb '24

Hans Leidekker (@hans) commented about dlls/advapi32/crypt.c: > } > > RegEnumKeyExW(hKey, dwIndex, provNameW, pcbProvName, NULL, NULL, NULL, NULL); > + > + if (pdwProvType) > + { > + HKEY hSubkey; > + DWORD size = sizeof(DWORD); > + > + RegOpenKeyW(hKey, provNameW, &hSubkey); > + RegQueryValueExW(hSubkey, L"Type", NULL, NULL, (BYTE*)pdwProvType, &size); You should check these calls for failure. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5046#note_62022

1 0

Re: [PATCH v2 0/1] MR5046: advapi32: CryptEnumProviders doesn't return pdwProvType when szProvName is NULL.
by Hans Leidekker (＠hans) 20 Feb '24

20 Feb '24

Hans Leidekker (@hans) commented about dlls/advapi32/tests/crypt.c: > ERROR_NO_MORE_ITEMS, GetLastError()); > > /* check expected versus actual values returned */ > + type = -1; > + providerLen = -1; > result = pCryptEnumProvidersA(dwIndex, NULL, 0, &type, NULL, &providerLen); > - ok(result && providerLen==cbName, "expected %i, got %i\n", (int)cbName, (int)providerLen); > + ok(result, "expected TRUE, got %ld\n", result); > + ok(type==dwType, "expected %ld, got %ld\n", dwType, type); > + ok(providerLen==cbName, "expected %i, got %i\n", (int)cbName, (int)providerLen); Please use spaces around operators, format DWORD with %lu and remove the casts. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5046#note_62020

1 0

Re: [PATCH v2 0/1] MR5046: advapi32: CryptEnumProviders doesn't return pdwProvType when szProvName is NULL.
by Hans Leidekker (＠hans) 20 Feb '24

20 Feb '24

Hans Leidekker (@hans) commented about dlls/advapi32/crypt.c: > } > > RegEnumKeyExW(hKey, dwIndex, provNameW, pcbProvName, NULL, NULL, NULL, NULL); > + > + if (pdwProvType) pdwProvType doesn't appear to be optional. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5046#note_62021

1 0

Re: [PATCH v2 0/1] MR652: vkd3d-shader/hlsl: Parse rasteriser-ordered view types.
by Henri Verbeet (＠hverbeet) 20 Feb '24

20 Feb '24

> I guess `hlsl_types_are_equal()` should be updated too? I added a check for HLSL_TYPE_UAV and "rasteriser_ordered", but I notice we don't compare formats there either for UAVs. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/652#note_62016

1 0

2025

2024

2023

2022