Commits on Source (75)
-
A driver program is introduced to coordinate test running on Windows, similarly to what "make test" does on Linux and macOS.
-
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
-
-
Some functions work with dereferences and need to know if they are lowered yet. This can be known checking if deref->offset.node is NULL or deref->data_type is NULL. I am using the latter since it keeps working even after the following patches that split deref->offset into constant and variable parts.
-
This uint will be used for the following: - Since SM4's relative addressing (the capability of passing a register as an index to another register) only has whole-register granularity, we will need to make the offset node express the offset in whole-registers and specify the register component in this uint, otherwise we would have to add additional / and % operations in the output binary. - If, after we apply constant folding and copy propagation, we determine that the offset is a single constant node, we can store all the offset in this uint constant, and remove the offset src. This allows DCE to remove a good bunch of the nodes previously required only for the offset constants, which makes the output more liteweight and readable, and simplifies the implementation of relative addressing when writing tpf in the following patches. In dump_deref(), we use "c" to indicate components instead of whole registers. Since now both the offset node and the offset uint are in components a lowered deref would look like: var[@42c + 2c] But, once we express the offset node in whole registers we will remove the "c" from the node part: var[@22 + 3c]
-
This is required to use SM4 relative addressing, because it is limited to whole-register granularity.
-
-
This field is now analogous to vkd3d_shader_register_index.rel_addr. Also, it makes sense to rename it now because all the constant part of the offset is now handled to hlsl_deref.const_offset. Consequently, it may also be NULL now.
-
-
If var->indexable, then the variable is given a unique register number, regardless of its lifetime.
-
-
-
-
-
-
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Makes it much clearer which register index is being written.
-
-
-
-
-
The resource could be destructed before the command list left open is executed; instead, we immediately perform the transition.
-
The resource could be destructed before the command list left open is executed; instead, we immediately perform the transition.
-
The resource could be destructed before the command list left open is executed; instead, we immediately perform the transition.
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
The profile cannot be reliably devised by analyzing the HLSL code, so it's useful to have it included in the file name.
-
So that they are dumped even if parsing fails, which is a circumstance in which one likely wants to see the problematic shader. The downside of that is that for shader types other than HLSL the profile is not written any more in the filename. This should not be a big problem, because in those cases the shader describes its own type. When dumping an HLSL shader, the id is brought in front of the profile in the file name, in order to make it more tab-friendly: when dealing with a directory full of shaders it's likely that the id determines the profile, but the other way around.
-
-
-
-
-
-
-
-
-
The used_mask value loaded from an additional tag/value pair is relative to the start column.
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
-
-
The hull shader barrier used for this was broken by I/O normalization, since vocp is no longer exposed to the spirv backend. Restore this barrier by checking for vocp during normalization instead.
-
I/O normalization removes this register type.
-
This is taken care of by prior I/O lowering. We no longer need to deal with this here.
-
Otherwise we always output "dcl_temps 1" even when no temp registers were used.
-
If the build fails some artifact files might not exist, and we don't want the script to fail just because of that.
-
On macOS vkd3d_shader_global_flags has underlying type unsigned long, while uint64_t is defined as unsigned long long. This difference causes a few warnings to be raised.
-
-
According to a clang diagnostic, redefining a typedef is C11, and we want to stick with C99.
-
-
-
-
The DXIL parser uses unsigned types even if the source code uses signed, so unsigned values may be negated.
-
-
Co-authored-by:
Evan Tang <etang@codeweavers.com> Evan Tang reported that new fixmes appeared on the shader_runner when running some of his tests after f50d0ae2. 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 bits 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.
-
None of these currently have any meaning, and none of these can currently be parsed as distinct tokens either (i.e. they will generate a syntax error anyway).
-
This is already handled by the preprocessor.
-
Done with `LC_ALL=C sort -f`.
-
-
RWBuffer objects would trigger a vkd3d_unreachable() in sm4_base_type(). It would be easy enough to add the required case there, but (manual, unfortunately) tests show that we aren't supposed to write constant buffer entries for objects in the first place, as you'd expect. This particular path ends up being exercised by vkd3d's internal UAV clear shaders, but unfortunately it looks like our RDEF data may have more issues; the ability to write tests for it would seem helpful.
-
Showing
- .gitignore 1 addition, 0 deletions.gitignore
- .gitlab-ci.yml 2 additions, 0 deletions.gitlab-ci.yml
- Makefile.am 33 additions, 2 deletionsMakefile.am
- gitlab/README 7 additions, 3 deletionsgitlab/README
- gitlab/build-crosstest 4 additions, 1 deletiongitlab/build-crosstest
- gitlab/build-linux 1 addition, 1 deletiongitlab/build-linux
- gitlab/build-mac 1 addition, 1 deletiongitlab/build-mac
- gitlab/build-mingw 2 additions, 2 deletionsgitlab/build-mingw
- gitlab/build.yml 1 addition, 0 deletionsgitlab/build.yml
- gitlab/test.yml 35 additions, 0 deletionsgitlab/test.yml
- include/vkd3d_d3dcompiler.h 2 additions, 21 deletionsinclude/vkd3d_d3dcompiler.h
- include/vkd3d_d3dcompiler_types.h 45 additions, 0 deletionsinclude/vkd3d_d3dcompiler_types.h
- include/vkd3d_utils.h 1 addition, 3 deletionsinclude/vkd3d_utils.h
- libs/vkd3d-shader/d3d_asm.c 10 additions, 13 deletionslibs/vkd3d-shader/d3d_asm.c
- libs/vkd3d-shader/d3dbc.c 6 additions, 15 deletionslibs/vkd3d-shader/d3dbc.c
- libs/vkd3d-shader/dxil.c 554 additions, 32 deletionslibs/vkd3d-shader/dxil.c
- libs/vkd3d-shader/hlsl.c 170 additions, 30 deletionslibs/vkd3d-shader/hlsl.c
- libs/vkd3d-shader/hlsl.h 51 additions, 7 deletionslibs/vkd3d-shader/hlsl.h
- libs/vkd3d-shader/hlsl.l 14 additions, 20 deletionslibs/vkd3d-shader/hlsl.l
- libs/vkd3d-shader/hlsl.y 253 additions, 20 deletionslibs/vkd3d-shader/hlsl.y
gitlab/test.yml
0 → 100644
include/vkd3d_d3dcompiler_types.h
0 → 100644
This diff is collapsed.