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
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
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
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
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
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
> 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
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