August 2023 - Wine-gitlab - list.winehq.org

[PATCH 0/5] MR295: vkd3d-shader: Extend vkd3d_shader_scan_descriptor_info, part 1/2.
by Zebediah Figura (＠zfigura) 07 Aug '23

07 Aug '23

There are two motivations for this: * First, the structure *almost* corresponds to D3D12_SHADER_INPUT_BIND_DESC, and if more elements were included, it could be used as-is for shader reflection. There is the quirk that currently we return scan information based on the shader instructions, whereas d3dcompiler shader reflection expects to get it from the shader reflection data (i.e. the RDEF chunk), which is particularly relevant in the case that the RDEF chunk is stripped. That said, even if we have to introduce an extra scan API to account for this difference, being able to reuse the same structure seems like a benefit. In order to reuse this structure, we need to add the following elements: - Register ID (added in part 1 of this series) - Sample count (added in part 2 of this series) - Flags or resource types to distinguish between typed, raw, and structured buffers. I have not decided which representation makes the most sense; opinions are welcome. * Second, I think it makes sense to use this reflection information internally in spirv.c (and potentially other compiler backends) to declare resources in the target environment, instead of parsing DCL instructions. The idea here is that this allows backends to be more agnostic as to how resources are declared (or inferred) in the frontend, while avoiding the need to synthesize those DCL instructions in the frontend either [especially since epenthesizing instructions is more expensive than converting them to NOPs.] In order to do that, we will need vkd3d_shader_scan_descriptor_info1 to cover everything that is currently covered by DCL instructions. This needs the same elements as above (register ID and sample count), but also: - Structure stride (added in part 2 of this series) - Constant buffer used width (added in part 2 of this series) I don't currently have a proof-of-concept using these new elements. On the other hand, since it's just an extension of an existing API, I figured that seemed less critical. This does conflict trivially with 280; I'm submitting it now since 280 is accepted, but due to Alexandre's vacation may not be committed soon, and since this is new API I'd rather get comments early anyway. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/295

3 10

[PATCH 0/2] MR3468: D3DX11 load texture from texture
by Alistair Leslie-Hughes (＠alesliehughes) 07 Aug '23

07 Aug '23

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

3 4

[PATCH 0/5] MR3524: gdiplus: Add missing PNG metadata properties
by Jeffrey Smith (＠whydoubt) 07 Aug '23

07 Aug '23

This adds the unit, date-time, and palette histogram metadata properties for PNG images to GDI+. With these changes, the properties returned match Windows for all files in the PNG samples suite found at http://www.schaik.com/pngsuite/ . -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3524

3 7

[PATCH 0/1] MR3521: sane.ds: Do the reverse convertion of frame edges before setting.
by Ilia Docin (＠IDocin) 07 Aug '23

07 Aug '23

Sane backends must attach a unit of either pixels or millimeters to scan area options. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3521

3 2

Re: [PATCH v3 0/3] MR3499: d3dx tests: Use compare_uint() in compare_float() instead of abs(). - approved
by Matteo Bruni (＠Mystral) 07 Aug '23

07 Aug '23

This merge request was approved by Matteo Bruni. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3499

1 0

Re: [PATCH v5 0/2] MR3473: whoami: Refactor and add more commands.
by Maxim Karasev (＠mxkrsv) 07 Aug '23

07 Aug '23

On Mon Aug 7 16:21:41 2023 +0000, Hans Leidekker wrote: > Yes, I tested current Wine. Here's a minimal working example: ```c #include <windows.h> #include <stdio.h> #include <locale.h> int __cdecl wmain(void) { setlocale(LC_ALL, ""); wprintf(L"Hello, world!\n"); wprintf(L"Привет, мир!\n"); wprintf(L"こんにちは世界！\n"); } ``` ```ShellSession $ winegcc -bx86_64-windows mwe.c -o mwe -municode $ wine mwe.exe Hello, world! $ LC_ALL=ru_RU.UTF-8 wine mwe.exe Hello, world! Привет, мир! ``` Without the `setlocale()` line only English is printed regardless of `LC_ALL`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3473#note_41515

1 0

[PATCH v2 0/3] MR3523: quartz: Fix some more memory leaks.
by Sven Baars (＠sbaars) 07 Aug '23

07 Aug '23

-- v2: strmbase: Fix a critical section leak (Valgrind). quartz/tests: Fix some memory leaks in test_add_source_filter() (Valgrind). https://gitlab.winehq.org/wine/wine/-/merge_requests/3523

3 4

[PATCH 0/4] MR299: vkd3d-shader/hlsl: Get SM4 texture allocation order and RDEF bind count for lowered combined samplers right.
by Francisco Casas (＠fcasas) 07 Aug '23

07 Aug '23

First, we have to distinguish between the "bind count" and the "allocation size" of variables. The "allocation size" affects the starting register id for the resource to be allocated next, while the "bind count" is determined by the last field actually used. The former may be larger than the latter. Currently we are calling `hlsl_reg.bind_count` to what should be `hlsl_reg.allocation_size`. So it is renamed in 2/4. The proper "bind count" (now computed when needed in 3/4) is important because it is what should appear in the RDEF table and some resource allocation rules depend on it For instance, for this shader: ``` texture2D texs[3]; texture2D tex; float4 main() : sv_target { return texs[0].Load(int3(0, 0, 0)) + tex.Load(int3(0, 0, 0)); } ``` the variable "texs" should show a "bind count" of 1, even though its "allocation size" is 3: ``` // Resource Bindings: // // Name Type Format Dim HLSL Bind Count // ------------------------------ ---------- ------- ----------- -------------- ------ // texs texture float4 2d t0 1 // tex texture float4 2d t3 1 ``` In particular, as shown in the tests in 1/4, textures go in this order: 1. Textures created from SM1-style samples. Those whose "bind count" is larger than 1, in the order of the tex1D/tex2D/tex3D/texCube instructions that create them. 2. Textures created from SM1-style samples. Those whose "bind count" is equal to 1, in the order of the tex1D/tex2D/tex3D/texCube instructions that create them. 3. Regular textures in order of declaration. Note that the difference between 1 and 2 is not given by the "allocation size" but the "bind count". This order is enforced in 4/4. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/299

3 6

Re: [PATCH v5 0/2] MR3473: whoami: Refactor and add more commands.
by Hans Leidekker (＠hans) 07 Aug '23

07 Aug '23

On Mon Aug 7 15:46:06 2023 +0000, Maxim Karasev wrote: > Which `whoami` was tested? If it was the current in-tree one, then it > works because it already uses `ConsoleWriteW()`. Yes, I tested current Wine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3473#note_41507

1 0

Re: [PATCH v5 0/2] MR3473: whoami: Refactor and add more commands.
by Maxim Karasev (＠mxkrsv) 07 Aug '23

07 Aug '23

On Thu Aug 3 17:58:39 2023 +0000, Hans Leidekker wrote: > I tried a username with non-ascii characters on Windows 10 and Wine and > whoami behaves the same. Non-ascii characters are rendered on the > console. When redirecting output non-ascii characters are replaced with '?'. Which `whoami` was tested? If it was the current in-tree one, then it works because it already uses `ConsoleWriteW()`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3473#note_41503

1 0