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