Commits 343c7942e1 and
94c74d2c00 moved applying the NonReadable
and Coherent decorations from spirv_compiler_emit_resource_declaration()
to spirv_compiler_build_descriptor_variable(), but unfortunately missed
the non-array path in the latter function.
The missing NonReadable decoration causes segmentation faults in
rasteriser-ordered-views.shader_test (among others) on my Intel SKL GT2
setup in particular.
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.
In the case two uav descriptors are mapped to the same variable, and one is
read from while the other is not, the variable would get the NonReadable
decorator, while being read from later.
The existing code reuses the same SPIR-V variable for all descriptors mapped to
the same Vulkan binding, and applies the NonReadable decoration based on the
VKD3D_SHADER_DESCRIPTOR_INFO_FLAG_UAV_READ only. This potentially causes the
decoration to be applied twice, should two non-read descriptors be mapped to
the same variable, which isn't allowed in SPIR-V, and the validator complains.
CTAB type correctly reflects matrix majority, unlike effects
type data that does not respond to majority modifiers at all.
It doesn't transpose default values either.
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
This fixes a lot of internal compiler errors with assignment operators,
especially bitwise ones. The bitwise-assignment test has the motivating
examples.
The existing code sets "stageFlags" to VK_SHADER_STAGE_ALL when
"use_vk_heaps" is true, but doesn't adjust the visibility. This
potentially violates the "Any two elements of pPushConstantRanges must
not include the same stage in stageFlags" constraint, and causes the
validation layers to complain accordingly.
We need to distinguish between the data type of a resource and the data
type of its components. These are usually the same except for 4.0
profiles where an array (or multi-dimensional array) of resources is
still considered a single resource, so it is possible for it to hold
more than one component.
In the latter case, we often need to access the type of a single
component (all components have the same type) instead of the type of the
whole array which often doesn't contain the required information, such
as sampler dimension.
This patch replaces the extern_resource.data_type field with the
extern_resource.component_type field, which points to the type of a
single component in the resource. Using it relieves many other code
paths from considering the possibility of the resource being an array.
This fixes runtime errors reported by UBSan, such as this:
vkd3d/libs/vkd3d-shader/tpf.c:6075:87: runtime error: load of value 7, which is not a valid value for type '_Bool'
when trying to compile shaders that contain UAV arrays on 4.0 profiles.
Before this commit, tpf.c accesses the
hlsl_type->e.resource.rasteriser_ordered
field, but on 4.0 and 4.1 profiles these code paths can also be reached
by UAV arrays which are HLSL_CLASS_ARRAY and this field is not supposed
to be accessed.
By coincidence, the value of hlsl_type->e.array.elements_count was being
read because these fields have the same offset in the hlsl_type.e union.
This causes a crash in the native compiler, but can only happen in
ps_5_0 were it is possible to declare structs that are both used in the
shader and contain strings.
struct
{
float a;
string b;
} apple = {1, "foobar"};
float4 main() : sv_target
{
return apple.a;
}
In our case, hlsl_type_get_component_offset() triggered an assertion
failure because it does not expect the string type. So this is replaced
by an hlsl_error().
