Diablo IV (closed beta) depends on DEVPKEY_Device_MatchingDeviceId being present for GPUs (once it is able to match GPU luid to the one obtained from dxgi). It also depends on the MatchingDeviceId conating "ven_" and "dev_" substrings. Without those it doesn't consider the gpu as valid, which currently results in the game complaining about no GPUs found. I guess that maybe it is trying to filter out software GPUs and such this way.
As far as my testing goes, DEVPKEY_Device_MatchingDeviceId has this form with hardware GPUs only and maybe with the recent enough Win10 or Win11.
The other two device properties being added are also queried by the game although they are not strictly needed for it.
--
v5: win32u: Set DEVPKEY_Device_RemovalPolicy for GPUs.
win32u: Set DEVPKEY_Device_BusNumber for GPUs.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2449
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54701
---
The private draw texture did not get evicted on reset(), causing us to
try to read from a non-existent texture with the new contest. For more
details see comment 9 on the bug.
--
v2: ddraw/tests: Show that SYSMEM | 3DDEVICE surfaces don't consume vidmem.
ddraw/tests: Native 64 bit ddraw has a video memory leak.
wined3d: Make video memory accounting a per-resource flag.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2478
This node type is intended for use during parse-time.
While we parse an indexing expression such as `a[3]`, we don't know if
it will end up as part of an expression (in which case it must be folded
into a load) or it is for the lhs of a store (in which case it must be
folded into the store's deref). This node type is used to represent these accesses and no longer rely on building an `hlsl_ir_load` for each array index or struct record access.
`hlsl_ir_index` chains are lowered into derefs when (and if) they are used to specify the lhs of an assignment. All `hlsl_ir_index`es are lowered into `hlsl_ir_load`s with a compilation pass.
The changes introduced in these series allow to solve the problem with the return variable of function calls presented in !93, and to properly support assignment to matrix indexes, which is something we are not doing correctly.
Further patches (in my [index node](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/index_node) branch) add support for indexing non-load expressions, such as `(a + b)[1]` and allowing to represent resource loads through `hlsl_ir_index`, so that `hlsl_ir_resource_store`s don't have to rely on `hlsl_ir_resource_load`s.
--
v6: vkd3d-shader/hlsl: Evaluate index before array.
vkd3d-shader/hlsl: Support column-major matrix indexing in the lhs.
vkd3d-shader/hlsl: Always load from a synthetic copy in add_load_component().
vkd3d-shader/hlsl: Remove add_load_index().
vkd3d-shader/hlsl: Use hlsl_ir_index for array and record access.
vkd3d-shader/hlsl: Introduce hlsl_ir_index.
tests: Test indexing of non-loads.
tests: Test side effects on indexes.
tests: Test matrix indexing on the lhs.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/124
a hotfix for the recent release of Persona 5 Royal.
--
v14: kernel32: Add semi-stub for RemoveDirectoryTransactedA/W().
kernel32: Add semi-stub for GetFileAttributesTransactedA/W().
kernel32: Add semi-stub for FindFirstFileTransactedA/W().
kernel32: Add semi-stub for DeleteFileTransactedA/W().
kernel32: Add semi-stub for CreateDirectoryTransactedA/W().
kernel32: Add semi-stub for CreateFileTransactedA/W().
https://gitlab.winehq.org/wine/wine/-/merge_requests/1145
Find only supports one Column to filter on.
The parser for this will be the same for both Find/Filter with the only different
is the Filter supports multiple columns.
In trying to keep this patch small, only WSTR/BSTR/Integer have been supported. (The Common cases).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2498