The hlsl_ir_compile node is introduced to represent the "compile"
syntax, and later the CompileShader() and ConstructGSWithSO()
constructs.
It basically represents a function call that remembers its arguments
using hlsl_srcs and keeps its own instruction block, which is discarded
when working on non-effect shaders.
For shader compilations it can be asserted that args_count is 1, and
that this argument (and the last node in hlsl_ir_effect_call.instrs)
is a regular hlsl_ir_call pointing to the declaration of the function
to be compiled.
The used UAV formats are explicitly added in the [require] section of
every test that uses them.
Some of these tests were failing on Intel UHD graphics 770 because of
missing support for additional UAV load types, explicitly requiring
these formats allows these tests to be skipped.
Currently we are skipping compilation tests ([* shader] blocks) on
missing capabilities. This is not really necessary and it is useful to
test shader compilation even on machines that can't run these tests.
So, this commit moves the checks to the [test] blocks, skipping them
entirely when caps are not met.
To make the effects of enum test_action values more explicit, these
are renamed to TEST_ACTION_SKIP_COMPILATION and
TEST_ACTION_SKIP_EXECUTION.
The current default is r32g32b32a32 but it requires special support
which is not available on all GPUs, so it is not a very convenient
default.
Instead of changing the default making it different from RTV resoures,
the format is required to always be explicit for UAVs.
The exceptions are counter_buffer and buffers with "stride", which don't
require a format because it is already implied.
This fixes a lot of internal compiler errors with assignment operators,
especially bitwise ones. The bitwise-assignment test has the motivating
examples.
This is achieved by means of creating a variable storing zero,
loading every array element, comparing if the non-constant index
matches the index of that element at runtime, and in that case
store the corresponding element in the variable.
This seems to be the same strategy that the native compiler uses.
I don't know the exact version that fixed this todo, but on the
same hardware this test was failing a couple of years ago, so
I presume something was fixed at some point. I am writing my
current driver version, but a lower one might turn out to be
sufficient.