- Nov 15, 2023
-
-
-
Passing less than 4.0 breaks the use of [require] with 'shader model < 4.0'.
-
- Nov 14, 2023
-
-
There is perhaps a bit of a trade-off involved here, but with the current state of things it's fairly hard to notice unexpected issues in the output.
-
The flag operand is omitted if IEEE strictness is specified.
-
The flag operand is omitted if IEEE strictness is specified.
-
- Nov 13, 2023
-
-
-
Noticed after test runner started crashing when tracing is enabled. Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
-
-
-
-
- Nov 10, 2023
-
-
-
-
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
- Nov 09, 2023
-
-
-
-
-
-
-
-
-
-
Besides reusing code, this now handles UAV types correctly.
-
-
Native does not always do this. For example, functions whose parameters are float and float1 always result in an "ambiguous function call" error. This does not fix any tests, because the relevant tests previously (incorrectly) succeeded, and now fail with: E5017: Aborting due to not yet implemented feature: Prioritize between multiple compatible function overloads. when they should simply fail.
-
vkd3d-shader/hlsl: Do not consider scalars and 1-dimensional vectors to be equivalent in function parameters.
-
The choice to store them in an rbtree was made early on. It does not seem likely that HLSL programs would define many overloads for any of their functions, but I suspect the idea was rather that intrinsics would be defined as plain hlsl_ir_function_decl structures [cf. 447463e5] and that some intrinsics that could operate on any type would therefore need many overrides. This is not how we deal with intrinsics, however. When the first intrinsics were implemented I made the choice disregard this intended design, and instead match and convert their types manually, in C. Nothing that has happened in the time since has led me to question that choice, and in fact, the flexibility with which we must accommodate functions has led me to believe that matching in this way was definitely the right choice. The main other designs I see would have been: * define each intrinsic variant separately using existing HLSL types. Besides efficiency concerns (i.e. this would take more space in memory, and would take longer to generate each variant), the normal type-matching rules don't really apply to intrinsics. [For example: elementwise intrinsics like abs() return the same type as the input, including preserving the distinction between float and float1. It is legal to define separate HLSL overloads taking float and float1, but trying to invoke these functions yields an "ambiguous function call" error.] * introduce new (semi-)generic types. This is far more code and ends up acting like our current scheme (with helpers) in a slightly more complex form. So I think we can go ahead and rip out this vestige of the original design for intrinsics. As for why to change it: rbtrees are simply more complex to deal with, and it seems unlikely to me that the difference is going to matter. I do not expect any program to define large quantities of intrinsics; linked list search should be good enough.
-
-
-
-
Instead of by vkd3d_shader_input_sysval_semantic.
-
-
Specifically, map COLOROUT to OUTPUT, and map INCONTROLPOINT to INPUT for domain shaders as well as hull shaders. Obscure the non-existent differences from the view of the backend.
-
sm4 does not use this; only sm1 does. In following patches we will normalize it to OUTPUT.
-
-
-
-