--
v3: vkd3d-shader/hlsl: Consistently use HLSL allocation functions.
vkd3d-shader/hlsl: Sort keywords.
vkd3d-shader/hlsl: Remove C++ comment lexing.
vkd3d-shader/hlsl: Remove some tokens from the lexer.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/426
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.
--
v5: ntdll: Tweak the binary representation of SRWLOCK.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4310
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.
--
v3: vkd3d-shader/tpf: Don't pass 0x4 as mask for vec4 constant src registers.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/438