September 2023 - Wine-GitLab

[PATCH v2 0/3] MR3784: nsiproxy.sys: Implement ipv6_forward_enumerate_all.
by Helix Graziani (＠TornadoCookie) Sept. 12, 2023

Sept. 12, 2023

-- v2: wldp: Add WldpQueryWindowsLockdownMode stub. nsiproxy.sys: Implement ipv6_forward_enumerate_all. wldp: Add WldpQueryWindowsLockdownMode stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/3784

3 4

[PATCH 0/1] MR3808: sensapi: Remove unnecessary includes.
by Zebediah Figura (＠zfigura) Sept. 12, 2023

Sept. 12, 2023

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

2 1

[PATCH 0/3] MR3807: include: Do not import strmif.idl in mediaobj.idl.
by Zebediah Figura (＠zfigura) Sept. 12, 2023

Sept. 12, 2023

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

2 3

[PATCH v3 0/1] MR3784: nsiproxy.sys: Implement ipv6_forward_enumerate_all.
by Helix Graziani (＠TornadoCookie) Sept. 12, 2023

Sept. 12, 2023

-- v3: nsiproxy.sys: Implement ipv6_forward_enumerate_all. https://gitlab.winehq.org/wine/wine/-/merge_requests/3784

2 1

[PATCH v7 0/5] MR3799: kernelbase: Add implementation of PerfSetULongCounterValue and PerfSetULongLongCounterValue
by Lorenzo Ferrillo (＠llde) Sept. 12, 2023

Sept. 12, 2023

These functions are used by Visual Studio 2019, when opening or converting some projects. Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it> -- v7: kernelbase: Check for PERF_SIZE_DWORD and PERF_SIZE_LARGE in PerfSetULongLongCounterValue and PerfSetULongCounterValue https://gitlab.winehq.org/wine/wine/-/merge_requests/3799

3 6

[PATCH 0/1] MR335: tests: Check the result of vkCreateGraphicsPipelines().
by Zebediah Figura (＠zfigura) Sept. 12, 2023

Sept. 12, 2023

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

4 3

[PATCH v2 0/2] MR331: vkd3d-shader/hlsl: Lower matrix swizzles.
by Francisco Casas (＠fcasas) Sept. 12, 2023

Sept. 12, 2023

As @nsivov pointed out, we are currently parsing matrix swizzles (e.g. mat._m12_m32) and creating an hlsl_ir_swizzle for the matrix itself. We are currently allowing shaders that use these to compile even though they are not working. While our compilation passes don't expect hlsl_ir_swizzles with matrix values, turns out we need them as a parse-time construct because we don't know if they will be used as the lhs of an assignment during parsing, similarly to hlsl_ir_indexes. This patch adds tests and a pass to lower these matrix swizzles. Implementing assignments with matrix swizzles is still pending. -- v2: vkd3d-shader/hlsl: Lower matrix swizzles. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/331

3 3

[PATCH v6 0/2] MR328: ci: Run the tests on macOS.
by Giovanni Mascellani (＠giomasce) Sept. 12, 2023

Sept. 12, 2023

-- v6: ci: Do not drop artifacts after 1 day. ci: Run the tests on macOS. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/328

3 3

Re: [PATCH v3 0/27] MR332: include: Fill in missing enum/struct/interfaces in vkd3d_d3d12.idl
by Henri Verbeet (＠hverbeet) Sept. 12, 2023

Sept. 12, 2023

Just a couple of nits: > ```diff > +typedef enum D3D12_DRED_ALLOCATION_TYPE > +{ > ... > + D3D12_DRED_ALLOCATION_TYPE_INVALID = 0xFFFFFFFF > +} D3D12_DRED_ALLOCATION_TYPE; > ``` Could we make that lower case hexadecimal? > ```diff > + D3D12_RESOURCE_ALLOCATION_INFO GetResourceAllocationInfo1( > + UINT visible_mask, > + UINT num_resource_descs, > + const D3D12_RESOURCE_DESC *resource_descs, > + D3D12_RESOURCE_ALLOCATION_INFO1 *resource_allocation_info1); > ``` We'd typically use "resource_desc_count" instead of "num_resource_descs" above. There are a couple of other "num_*" parameters in this MR as well. Ultimately I'm not too bothered about these, so don't worry about it if you feel changing them is too much effort, but if you did change them that would certainly be welcome. > ```diff > + void CreateSamplerFeedbackUnorderedAccessView( > + ID3D12Resource *targeted_resource, > + ID3D12Resource *feedback_resource, > + D3D12_CPU_DESCRIPTOR_HANDLE dest_descriptor); > ``` Similarly, we'd typically use "dst_descriptor" above and for similar parameters. > ```diff > +interface ID3D12Device6 : ID3D12Device5 > +{ > + HRESULT SetBackgroundProcessingMode( > + D3D12_BACKGROUND_PROCESSING_MODE Mode, > + D3D12_MEASUREMENTS_ACTION MeasurementsAction, > + HANDLE hEventToSignalUponCompletion, > + BOOL*pbFurtherMeasurementsDesired); > +} > ``` I'd suggest something like the following: ``` interface ID3D12Device6 : ID3D12Device5 { HRESULT SetBackgroundProcessingMode( D3D12_BACKGROUND_PROCESSING_MODE mode, D3D12_MEASUREMENTS_ACTION action, HANDLE event, BOOL *further_measurements_desired); } ``` > ```diff > +cpp_quote("#define D3D12_ENCODE_BASIC_FILTER(min, mag, mip, reduction) \\") > +cpp_quote(" ((D3D12_FILTER) ( \\") > +cpp_quote(" (((min) & D3D12_FILTER_TYPE_MASK) << D3D12_MIN_FILTER_SHIFT) | \\") > +cpp_quote(" (((mag) & D3D12_FILTER_TYPE_MASK) << D3D12_MAG_FILTER_SHIFT) | \\") > +cpp_quote(" (((mip) & D3D12_FILTER_TYPE_MASK) << D3D12_MIP_FILTER_SHIFT) | \\") > +cpp_quote(" (((reduction) & D3D12_FILTER_REDUCTION_TYPE_MASK) << D3D12_FILTER_REDUCTION_TYPE_SHIFT)))") > + > +cpp_quote("#define D3D12_ENCODE_ANISOTROPIC_FILTER(reduction) \\") > +cpp_quote(" ((D3D12_FILTER) ( \\") > +cpp_quote(" D3D12_ANISOTROPIC_FILTERING_BIT | \\") > +cpp_quote(" D3D12_ENCODE_BASIC_FILTER(D3D12_FILTER_TYPE_LINEAR, \\") > +cpp_quote(" D3D12_FILTER_TYPE_LINEAR, \\") > +cpp_quote(" D3D12_FILTER_TYPE_LINEAR, \\") > +cpp_quote(" reduction))) ") > ``` We'd typically put the operators at the start of the next line; compare e.g. the existing D3D12_DECODE_IS_ANISOTROPIC_FILTER and D3D12_ENCODE_SHADER_4_COMPONENT_MAPPING macros. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/332#note_45105

1 0

[PATCH v8 0/13] MR317: vkd3d-shader: Begin validating the generated IR.
by Giovanni Mascellani (＠giomasce) Sept. 12, 2023

Sept. 12, 2023

The validation code is meant both as a check that the frontend is behaving properly and as a sort of the documentation to establish what is allowed and what is not in the IR. ~~Currently an assertion is thrown if validation fails. I realize this is a rather strong proposal, but it's of course up for debate. In theory asserting here is the right thing, as it is expected that the frontend is generating correct IR code. However vkd3d is already used in production for many programs, and it could very well be that some of those are working properly even if the generated IR is somewhat out of specs; allowing the assertion might cause regressions as soon as enough checks are implemented in the validator. Please let me know your opinions.~~ **Solved in favor of a softer failure, and only when validation is enabled** -- v8: vkd3d-shader/ir: Validate source parameters. vkd3d-shader/ir: Validate destination parameters. vkd3d-shader/ir: Validate register types. vkd3d-shader/ir: Validate instruction handlers. vkd3d-shader/ir: Introduce a boilerplate to validate the generated IR. vkd3d-shader: Embed the parsing location in vkd3d_shader_instruction. vkd3d-shader/dxil: Destroy the SM6 parser on parsing errors. vkd3d-shader/tpf: Destroy the SM4 parser on parsing errors. vkd3d-shader/d3dbc: Destroy the SM1 parser on parsing errors. vkd3d-shader/d3dbc: Skip DCL semantic tokens properly. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/317

3 15