- Jan 19, 2023
-
-
-
tests/shader_runner: Explicitly track the expected shader compilation HRESULT instead of using a boolean flag.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
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().
-
-