- Jan 19, 2023
-
-
-
-
-
-
-
-
-
validate_static_object_references() validates that uninitialized static objects are not referenced in the shader. In case a static variable contains both numeric and object types, the "Static variables cannot have both numeric and resource components." error should preempt uninitialized numeric values to reach further compilation steps.
-
Note that in the future we should call validate_static_object_references() after DCE and pruning branches, because shaders such as these compile (at least in more modern versions of the native compiler): Branch pruning: ``` static RWTexture2D<float> tex; float4 main() : sv_target { if (0) { tex[int2(0, 0)] = 2; } return 0; } ``` DCE: ``` static Texture2D tex; uniform uint i; float4 main() : sv_target { float4 unused = tex.Load(int3(0, 1, 2)); return 0; } ``` These are "todo" tests in hlsl-static-initializer.shader_test that depend on this.
-
-
-
We are currently not initializing static values to zero by default. Consider the following shader: ```hlsl static float4 va; float4 main() : sv_target { return va; } ``` we get the following output: ``` ps_5_0 dcl_output o0.xyzw dcl_temps 2 mov r0.xyzw, r1.xyzw mov o0.xyzw, r0.xyzw ret ``` where r1.xyzw is not initialized. This patch solves this by assigning the static variable the value of an uint 0, and thus, relying on complex broadcasts. This seems to be the behaviour of the 9.29.952.3111 version of the native compiler, since it retrieves the following error on a shader that lacks an initializer on a data type with object components: ``` error X3017: cannot convert from 'uint' to 'struct <unnamed>' ```
-
- Jan 13, 2023
-
-
We have a different system of generating intrinsics, which makes it easier to deal with "polymorphic" arithmetic functions. Defining and storing intrinsics as hlsl_ir_function_decls would also require more space in memory (and more optimization passes to get rid of the parameter variables), and doesn't really save us any effort in terms of source code.
-
-
-
-
-
- Jan 11, 2023
-
-
-
-
-
-
-
-
-
-
-
I assume this is a typo, right now it doesn't make sense. Signed-off-by:
Fabian Maurer <dark.shadow4@web.de>
-
Using add_unary_arithmetic_expr() instead of hlsl_new_unary_expr() allows the intrinsic to work with matrices. Otherwise we get: E5017: Aborting due to not yet implemented feature: Copying from unsupported node type. because an HLSL_IR_EXPR reaches split_matrix_copies().
-
-
-
Some intrinsics have different rules for the allowed data types than expressions: - Vectors and matrices at the same time are not allowed, regardless of their dimensions. Even if they have the same number of components. - Any combination of matrices is always allowed, even those when no matrix fits inside another, e.g.: float2x3 is compatible with float3x2, resulting in float 2x2. The common data type is the min on each dimension. This is the case for max, pow, ldexp, clamp and smoothstep; which suggest that it is the case for all intrinsics where the operation is applied element-wise. Tests for mul() are also added as a counter-example where the operation is not element-wise.
-
-
-
- Dec 07, 2022
- Nov 21, 2022
-
-
vkd3d-shader: Introduce DESCRIPTOR_INFO_FLAG_UAV_ATOMICS and always declare UAV images with known type for atomic ops. Atomic ops on images with Unknown type will cause SPIR-V validation failure, and assertion failure in Mesa debug builds. D3D12 allows atomics on typed buffers, and this requires a distinction to be made between UAV reads and atomic ops. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53874
-
Until vkd3d-shader is patched, an atomic op on a typed buffer where StorageImageReadWithoutFormat is available will cause SPIR-V validation failure, and assertion in Mesa debug builds, because the image will be declared with Unknown format.
-
- Nov 18, 2022
-
-
Unlike compatible_data_types() and implicit_compatible_data_types(), this function is intended to be symmetrical. So it makes sense to preserve the names "t1" and "t2" for the arguments.
-
-