Evan Tang reported that new fixmes appeared on the shader_runner when
running some of his tests after
f50d0ae2cbc5ee2a26fedd7b8aac2def62decd6c.
vkd3d:652593:fixme:shader_sm4_read_src_param Unhandled mask 0x4.
The change to blame seems to be this added line in
sm4_src_from_constant_value().
+ src->swizzle = VKD3D_SHADER_NO_SWIZZLE;
On tpf binaries the last 12 bytes of each src register in an instruction
specify the swizzle, and there are 5 possible combinations:
Dimension NONE
-------- 00
Dimension SCALAR
-------- 01
Dimension VEC4, with a 4 bit writemask:
---- xxxx 00 01
Dimension VEC4, with an 8 bit swizzle:
xx xx xx xx 01 01
Dimension VEC4, with a 2bit scalar dimension number:
------ xx 10 01
So far, we have only seen src registers use 4 bit writemasks in a
single case: for vec4 constants, and it is always zero.
So we expect this:
---- 0000 00 01
Now, I probably wanted to initialize src->swizzle to zero when writing
constants, but VKD3D_SHADER_NO_SWIZZLE is not zero, it is actually the
default swizzle:
11 10 01 00
And the last 4 bits (0x4) get written in the mask part, which causes
the reader to complain.
--
v2: vkd3d-shader/tpf: Don't pass 0x4 as mask for vec4 constant src registers.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/438
More preparatory work to declare I/O variables from the signature.
--
v2: vkd3d-shader/spirv: Use register counts from the signature and shader desc.
vkd3d-shader: Store the control point counts in struct vkd3d_shader_desc.
vkd3d-shader/spirv: Use the array sizes for shader phase builtins as well.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/439
There are applications that uses SRWLOCK in an invalid way and then checks its binary
representation. Specifically they releases an unlocked SRWLOCK then check its bit pattern is
all-ones.
Tweak the representation a bit so they are happy.
--
v2: ntdll: Tweak the binary representation of SRWLOCK.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4310
There are applications that uses SRWLOCK in an invalid way and then checks its binary
representation. Specifically they releases an unlocked SRWLOCK then check its bit pattern is
all-ones.
Tweak the representation a bit so they are happy.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4310
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v2: vkd3d-shader/tpf: Initial support for writing fx_4_0/fx_4_1 binaries.
vkd3d-shader/hlsl: Handle effect group statement.
vkd3d-shader/hlsl: Add variables for techniques.
vkd3d-shader/hlsl: Rename rule for top-level techniques.
vkd3d-shader/hlsl: Add 'fxgroup' token.
tests: Add some tests for effects groups syntax.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/443
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55842
The bug blames commit 059094c1c18ddc33b04eac53a72fd0eb7510be94 ("ntdll: Define heap block's BLOCK_FLAG_LFH as 0x80.") but actually before the blamed commit that worked essentially by chance.
The problem the patch is solving is that RtlValidateHeap() currently always fails for LFH blocks allocated from large block memory (vs subheap blocks). That can happen for large enough LFH block sizes. In case of the regressed game the user of RtlValidateHeap() is msvcr80.msvcrt_heap_free() which uses HeapValidate() to guess the heap used to allocate the pointer to free. I am attaching a standalone test program which can be used to reproduce the problem without the patch.
[test_lfh_validate.c](/uploads/006b04a9a00ffb7949956b66a275d5cf/test_lfh_validate.c)
--
v3: ntdll: Fix pending free block validation in heap_validate() for LFH blocks.
ntdll: Handle LFH blocks allocated in large blocks in heap_validate_ptr().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4232