January 2024 - wine-gitlab

Re: [PATCH v3 0/3] MR4857: Draft: gdi32,win32u: Implement D3DKMTEnumAdapters2.
by Krzysztof Bogacki (＠Saancreed) 19 Jan '24

19 Jan '24

On Fri Jan 19 04:03:17 2024 +0000, Zhiyi Zhang wrote: > D3DKMT_ENUMADAPTERS2 already has an array for this. I think you can > avoid this memory allocation. Indeed, but I thought it would be safer to allocate some memory for a temporary working area, try enumerating adapters and only copy the result if the entire operation did not fail halfway through rather than using the array I was passed by the caller directly and risk writing some partially misleading garbage to it. I also wasn't sure how to proceed in such case: if I already wrote some LUIDs and handles, should I try to `memset(0)` them just in case or leave the data there and trust that all callers of this API will ignore whatever was written, treating the content as unspecified? It's also somewhat tricky to cause Windows to fail here so I don't know how exactly does it behave when it encounters some error internally. Copying the full result only on full success seemed like an easy way out that allowed me to not bother figuring this out, even if it costs an extra allocation. But I can revert to writing to `pAdapters` directly if you'd prefer it that way. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_58256

1 0

Re: [PATCH v3 0/3] MR4857: Draft: gdi32,win32u: Implement D3DKMTEnumAdapters2.
by Krzysztof Bogacki (＠Saancreed) 19 Jan '24

19 Jan '24

On Fri Jan 19 04:03:16 2024 +0000, Zhiyi Zhang wrote: > Please add a test for this. While two separate Windows machines on which I queried the size of array to allocate did return 32, this number isn't something that's documented anywhere and probably shouldn't be relied on directly. I can add a test that checks that `NumAdapters` is always set to `32` if `pAdapters` is `NULL` and it might even pass on most if not all Windows versions currently out there but Microsoft could one day decide that in such cases `64` should now be returned and there would be nothing wrong with that… or so I believe. Otherwise, this is already tested by first `ok(enum_adapters_2_desc.NumAdapters, "Expect not zero.\n");`, although not very strictly. I'm also not sure what would Windows return on systems with more than 32 adapters. Can Windows even support that many GPUs at the same time? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_58255

1 0

Re: [PATCH v3 0/3] MR4857: Draft: gdi32,win32u: Implement D3DKMTEnumAdapters2.
by Krzysztof Bogacki (＠Saancreed) 19 Jan '24

19 Jan '24

On Fri Jan 19 04:03:15 2024 +0000, Zhiyi Zhang wrote: > You can remove this line. Together with the +1 above, this was meant to verify that array entries past number returned by the call that actually fills them are untouched (and +1 was for the case where the implementation returns exactly as many adapters as the length of the array that was passed). If you believe it's not something worth testing, I'll just remove this and +1 above. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_58254

1 0

[PATCH v2 0/2] MR569: tests/shader_runer: Support SRV buffers.
by Francisco Casas (＠fcasas) 19 Jan '24

19 Jan '24

This allows to declare SRV buffers in the shader tests using `[buffer srv n]` blocks, and passing them to the different backends. Also, 1/2 includes a missing bit required to parse `Buffer<>` types in the HLSL compiler. This is a step towards supporting StructuredBuffer types in further patches. -- v2: tests/shader_runner: Support SRV buffers. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/569

2 2

[PATCH 0/2] MR569: tests/shader_runer: Support SRV buffers.
by Francisco Casas (＠fcasas) 19 Jan '24

19 Jan '24

This allows to declare SRV buffers in the shader tests using `[buffer srv n]` blocks, and passing them to the different backends. Also, 1/2 includes a missing bit required to parse `Buffer<>` types in the HLSL compiler. This is a step towards supporting StructuredBuffer types in further patches. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/569

3 4

Re: [PATCH v7 0/1] MR4343: setupapi: Add stub for DriverStoreFindDriverPackageW
by Fabian Maurer (＠DarkShadow44) 19 Jan '24

19 Jan '24

On Mon Nov 20 18:35:34 2023 +0000, Alex Henrie wrote: > Sounds reasonable. Does that mean you have no objections to merging this > patch as it currently stands? any news on this? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4343#note_58246

1 0

Re: [PATCH v3 0/5] MR4877: include: Add some ncrypt definitions. - approved
by Alexandre Julliard (＠julliard) 19 Jan '24

19 Jan '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4877

1 0

[PATCH v6 0/3] MR4886: msttsengine: Implement basic functionality with Flite.
by Shaun Ren (＠shaunren) 19 Jan '24

19 Jan '24

-- v6: msttsengine: Implement ISpTTSEngine::Speak. msttsengine: Implement ISpTTSEngine::GetOutputFormat. msttsengine: Import and use Flite 2.2. https://gitlab.winehq.org/wine/wine/-/merge_requests/4886

1 0

Re: [PATCH v4 0/3] MR4875: wined3d: Hook up sm1 support in the Vulkan backend. - approved
by Alexandre Julliard (＠julliard) 19 Jan '24

19 Jan '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4875

1 0

Re: [PATCH v2 0/1] MR4815: wined3d: Update reported AMD driver version. - approved
by Alexandre Julliard (＠julliard) 19 Jan '24

19 Jan '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4815

1 0

2025

2024

2023

2022

wine-gitlab January 2024