- wine-gitlab - winehq.org

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

15 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. -- v2: vkd3d-shader/d3dbc: Use the bind count instead of the allocation size in d3dbc.c. vkd3d-shader/hlsl: Simplify computation of allocation size. vkd3d-shader/hlsl: Sort synthetic separated samplers first for SM4. vkd3d-shader/tpf: Put the actual bind count in the RDEF table. vkd3d-shader/hlsl: Rename hlsl_reg.bind_count to hlsl_reg.allocation_size. tests: Test texture allocation ordering in complex scenarios. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/299

5 10

[PATCH v5 0/1] MR3567: jscript: handle Array.prototype.splice with omitted deleteCount
by Yuxuan Shui (＠yshui) 15 Aug '23

15 Aug '23

Current code handles omitted deleteCount but assumes it to be zero in that case. Instead an omitted deleteCount means delete everything from `start`. This prevents Adobe sign-in page from loading. -- v5: jscript: fix Array.prototype.splice with omitted deleteCount in html mode https://gitlab.winehq.org/wine/wine/-/merge_requests/3567

3 3

[PATCH v4 0/1] MR3567: jscript: handle Array.prototype.splice with omitted deleteCount
by Yuxuan Shui (＠yshui) 15 Aug '23

15 Aug '23

Current code handles omitted deleteCount but assumes it to be zero in that case. Instead an omitted deleteCount means delete everything from `start`. This prevents Adobe sign-in page from loading. -- v4: jscript: fix Array.prototype.splice with omitted deleteCount in html mode https://gitlab.winehq.org/wine/wine/-/merge_requests/3567

3 5

[PATCH 0/1] MR3574: configure: don't require pcsclite header for winscard
by David McFarland (＠corngood) 15 Aug '23

15 Aug '23

The header is unused, and the header check fails with: configure:7860: checking for PCSC/pcsclite.h configure:7860: gcc -m32 -c -g -O2 conftest.c >&5 In file included from conftest.c:50: [...]/include/PCSC/pcsclite.h:45:10: fatal error: wintypes.h: No such file or directory 45 | #include <wintypes.h> | ^~~~~~~~~~~~ Fixes: d405a688ba6b5042775d733f57d00ba6318e1d0f -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3574

3 4

Re: [PATCH v2 0/1] MR3447: ntdll/unix: NtTerminateThread should accept NULL handle
by Ake Rehnman (＠ake.rehnman) 15 Aug '23

15 Aug '23

On Tue Aug 15 14:52:18 2023 +0000, Ake Rehnman wrote: > ```plaintext > int test_ntterminatethread_proc_failed; > DWORD WINAPI test_ntterminatethread_proc( void *arg ) > { > DWORD status = (UINT_PTR)arg; > status = pNtTerminateThread(0, status); > test_ntterminatethread_proc_failed = 1; > return status; > } > /* verifies NtTerminateThread accepts NULL handle */ > static void test_terminate_thread(void) > { > HANDLE thread; > DWORD exitcode; > NTSTATUS status; > test_ntterminatethread_proc_failed = 0; > status = pNtCreateThreadEx( &thread, THREAD_ALL_ACCESS, NULL, GetCurrentProcess(), > (PRTL_THREAD_START_ROUTINE)test_ntterminatethread_proc, > (void*)0x1234, 0, 0, 0, 0, NULL ); > ok( status == STATUS_SUCCESS, "Got unexpected status %#lx.\n", > status ); > WaitForSingleObject(thread, INFINITE); > GetExitCodeThread(thread, &exitcode); > ok( exitcode == 0x1234, "NtTerminateThread failed exitcode = %lx\n", (long)exitcode); > ok( test_ntterminatethread_proc_failed == 0, "NtTerminateThread failed\n"); > } > ``` > Better? The reason it was not in the test case is I already tested it in the snippet in the Bugzilla ticket. The test case was more for making sure it did not pop up again. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3447#note_42339

1 0

Re: [PATCH v2 0/1] MR3447: ntdll/unix: NtTerminateThread should accept NULL handle
by Ake Rehnman (＠ake.rehnman) 15 Aug '23

15 Aug '23

On Tue Aug 15 14:30:00 2023 +0000, Alexandre Julliard wrote: > > If arg == 0x1234 and NtTerminateThread returns to the caller > GetExitCodeThread status would be some other value than 0x1234 unless > NtTerminateThread would return 0x1234 to the caller (which it does not). > It's possible that it sets the exit code without exiting, this is what > NtTerminateProcess does. It really needs an explicit test. ```plaintext int test_ntterminatethread_proc_failed; DWORD WINAPI test_ntterminatethread_proc( void *arg ) { DWORD status = (UINT_PTR)arg; status = pNtTerminateThread(0, status); test_ntterminatethread_proc_failed = 1; return status; } /* verifies NtTerminateThread accepts NULL handle */ static void test_terminate_thread(void) { HANDLE thread; DWORD exitcode; NTSTATUS status; test_ntterminatethread_proc_failed = 0; status = pNtCreateThreadEx( &thread, THREAD_ALL_ACCESS, NULL, GetCurrentProcess(), (PRTL_THREAD_START_ROUTINE)test_ntterminatethread_proc, (void*)0x1234, 0, 0, 0, 0, NULL ); ok( status == STATUS_SUCCESS, "Got unexpected status %#lx.\n", status ); WaitForSingleObject(thread, INFINITE); GetExitCodeThread(thread, &exitcode); ok( exitcode == 0x1234, "NtTerminateThread failed exitcode = %lx\n", (long)exitcode); ok( test_ntterminatethread_proc_failed == 0, "NtTerminateThread failed\n"); } ``` Better? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3447#note_42338

1 0

[PATCH 0/5] MR3534: wined3d: Move GL declarations to wined3d_gl.h, part 3.
by Zebediah Figura (＠zfigura) 15 Aug '23

15 Aug '23

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

3 6

Re: [PATCH v2 0/2] MR3431: wined3d: Fix clears of the current render target in Vulkan - approved
by Jan Sikorski (＠jsikorski) 15 Aug '23

15 Aug '23

This merge request was approved by Jan Sikorski. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3431

1 0

Re: [PATCH v2 0/1] MR3447: ntdll/unix: NtTerminateThread should accept NULL handle
by Alexandre Julliard (＠julliard) 15 Aug '23

15 Aug '23

> If arg == 0x1234 and NtTerminateThread returns to the caller GetExitCodeThread status would be some other value than 0x1234 unless NtTerminateThread would return 0x1234 to the caller (which it does not). It's possible that it sets the exit code without exiting, this is what NtTerminateProcess does. It really needs an explicit test. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3447#note_42334

1 0

Re: [PATCH v2 0/1] MR3447: ntdll/unix: NtTerminateThread should accept NULL handle
by Ake Rehnman (＠ake.rehnman) 15 Aug '23

15 Aug '23

On Tue Aug 15 13:21:04 2023 +0000, Jinoh Kang wrote: > No, I don't think so. > How do you determine whether `NtTerminateThread()` actually terminated > the thread on the spot, or just returned normally to > `test_ntterminatethread_proc` which *in turn* returned to the system? > There's nothing between `status = pNtTerminateThread(0, status);` and > `return status;` that signals that the thread was still alive after the call. > On the other hand, we *do* test that `NtTerminateProcess(0, 195);` > returns to the caller without immediately terminating the process. See > `dlls/kernel32/tests/loader.c` for details. ``` DWORD WINAPI test_ntterminatethread_proc( void *arg ) { DWORD status = (UINT_PTR)arg; status = pNtTerminateThread(0, status); return status; } ``` If arg == 0x1234 and NtTerminateProcess returns to the caller GetExitCodeThread status would be some other value than 0x1234 unless NtTerminateThread would return 0x1234 to the caller (which it does not). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3447#note_42325

1 0

2025

2024

2023

2022

wine-gitlab