January 2024 - wine-gitlab

Re: [PATCH v2 0/4] MR539: vkd3d-shader/ir: Avoid DWORDs. - approved
by Alexandre Julliard (＠julliard) 04 Jan '24

04 Jan '24

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

1 0

Re: [PATCH v8 0/5] MR530: Add a few validation checks. - approved
by Alexandre Julliard (＠julliard) 04 Jan '24

04 Jan '24

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

1 0

Re: [PATCH v4 0/2] MR527: vkd3d-shader: Implement I/O for shader model 2. - approved
by Alexandre Julliard (＠julliard) 04 Jan '24

04 Jan '24

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

1 0

[PATCH 0/3] MR540: vkd3d: Recognise some more flags in debug_vk_queue_flags().
by Henri Verbeet (＠hverbeet) 04 Jan '24

04 Jan '24

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

3 4

[PATCH 0/4] MR539: vkd3d-shader/ir: Avoid DWORDs.
by Henri Verbeet (＠hverbeet) 04 Jan '24

04 Jan '24

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

3 5

[PATCH v14 0/18] MR531: Draft: vkd3d: Assorted fixes for MoltenVK.
by Giovanni Mascellani (＠giomasce) 04 Jan '24

04 Jan '24

-- v14: tests: Mark the tessellation pipeline as buggy on MoltenVK. tests: Mark geometry shaders as buggy on MoltenVK. tests: Mark ReadFromSubresource() and WriteToSubresource() as todo on MoltenVK. tests: Mark a test related to instanced draws as buggy on MoltenVK. tests: Mark count buffers as buggy on MoltenVK. tests: Mark a timestamp query test as buggy on MoltenVK. tests: Mark clip distance as unsupported on MoltenVK. tests: Mark cull distance as buggy on MoltenVK. tests: Mark unbounded descriptor ranges as buggy on MoltenVK. tests: Mark loading from stencil as buggy on MoltenVK. tests: Mark resource arrays as buggy on MoltenVK. tests: Mark predicated rendering as buggy on MoltenVK. tests: Mark streaming output as buggy on MoltenVK. tests: Mark some sampling tests as buggy on MoltenVK. vkd3d-shader/spirv: Specify behavior for bit field instructions. tests: Use a uint target for rendering uint data. vkd3d: Specify the aspect when creating NULL UAVs. ci: Dump the d3d12 summary line in the CI log. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/531

2 18

Re: [PATCH v4 0/5] MR464: vkd3d-shader/spirv: Declare I/O registers from the signature.
by Giovanni Mascellani (＠giomasce) 04 Jan '24

04 Jan '24

While debugging a test failure on MoltenVK I discovered that commit 66cb2815f0662713c3255113255cfd7cf5e406fb triggers a validation failure in `test_shader_input_output_components()`: ``` VUID-RuntimeSpirv-OpTypeVector-06816(ERROR / SPEC): msgNum: 79036675 - Validation Error: [ VUID-RuntimeSpirv-OpTypeVector-06816 ] Object 0: handle = 0x590000000059, type = VK_OBJECT_TYPE_SHADER_MODULE; Object 1: handle = 0x5a000000005a, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0x4b60103 | vkCreateGraphicsPipelines(): pCreateInfos[0] starting at Location 2 Component 0 the Output (VK_SHADER_STAGE_VERTEX_BIT) has a Vec4 while Input (VK_SHADER_STAGE_FRAGMENT_BIT) as a Vec3. Enable VK_KHR_maintenance4 device extension to allow relaxed interface matching between input and output vectors. The Vulkan spec states: Any OpTypeVector output interface variables must not have a higher Component Count than a matching OpTypeVector input interface variable (https://www.khronos.org/registry/vulkan/specs/1.2/html/vkspec.html#VUID-Run…) ``` The validation error seems to be related to the MoltenVK failure I'm debugging, but there must be something more because testing on the parent commit gets rid of the validation error, but not of the MoltenVK failure, which incidentally is: ``` [mvk-error] VK_ERROR_INITIALIZATION_FAILED: Render pipeline compile failed (Error code 3): Fragment input(s) `user(locn2_3)` mismatching vertex shader output type(s) or not written by vertex shader. d3d12:11826: Test 4: Test failed: Got {0.00000000e+00, 1.00000000e+00, 0.00000000e+00, 1.00000000e+00}, expected {0.00000000e+00, 1.00000000e+00, 0.00000000e+00, 2.50000000e-01} at (0, 0). ``` Even if the validation error is not the direct cause of the failure, it looks like something we'd want to fix anyway. I intent to spend some more time on this, but if in the meantime somebody more expert of I/O interfaces wants to have a look, now you know! -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/464#note_56708

1 0

[PATCH v5 0/2] MR4774: msvcrt: Compare environmental variable names case insensitively
by Zsolt Vadász (＠zsoltiv) 04 Jan '24

04 Jan '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56134 -- v5: msvcrt/tests: Test case insensitivity of getenv() and _wgetenv() msvcrt: Compare environmental variable names case insensitively https://gitlab.winehq.org/wine/wine/-/merge_requests/4774

3 3

[PATCH 0/1] MR4785: windows.media.speech/tests: Remove obsolete workarounds.
by Bernhard Kölbl (＠besentv) 04 Jan '24

04 Jan '24

These got obsolete with eaca0f44be41e0543dd2f3909012cdcf041328a7. Signed-off-by: Bernhard Kölbl <bkoelbl(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4785

2 1

Re: [PATCH v2 0/3] MR4781: ddraw: Make sure that sysmem surfaces remain coherent when not locked.
by Zebediah Figura (＠zfigura) 04 Jan '24

04 Jan '24

d2d9f713d forces us to create a separate wined3d_texture for texturing or RTV usage. I don't know why it was done this way instead of just continuing to allow CPU textures to be used as a texture/RTV; unfortunately neither the commit message nor the patches as submitted on wine-devel give any explanation. Even at that point the offending Emperor texture wasn't created with any bind flags. (Despite the fact that a color fill uses an RTV, it wasn't created with WINED3D_BIND_RENDER_TARGET; we don't currently validate that.) ee7d047dd55a forces all sysmem textures to get a draw texture. That means that the color fill acts on the draw texture instead of the sysmem texture, and the subsequent blits use ddraw_surface_get_any_texture() and hence pick the draw texture since that location is valid. It does slightly bother me that we're reimplementing all this logic on the client side, but I guess there was a reason for doing it this way... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4781#note_56702

1 0

2025

2024

2023

2022

wine-gitlab January 2024