- Sep 24, 2024
-
-
Feifan He authored
-
Francisco Casas authored
-
Francisco Casas authored
-
Francisco Casas authored
-
Henri Verbeet authored
Perhaps the existing code is safe in practice, but doing the check properly avoids having to make that determination.
-
Henri Verbeet authored
-
Henri Verbeet authored
-
Atharva Nimbalkar authored
-
Henri Verbeet authored
-
Atharva Nimbalkar authored
-
Conor McCarthy authored
-
Conor McCarthy authored
-
Giovanni Mascellani authored
SPIR-V images have a "depth" parameter that, as far as I understand (the spec doesn't look terribly clear in that regard), specifies whether the image can be used for depth-comparison operations. In TPF (and therefore in VSIR) the same information is specified on the sampler type instead of on the image type. This puts us in a hard spot, because in principle an image can be used with many different samplers, and the mapping might even be unknown at compilation time, so it's not clear how we should define our images. We currently have some algorithms to deal with that, but they are incomplete and lead to SPIR-V validation errors like: Expected Image to have the same type as Result Type Image %63 = OpSampledImage %62 %59 %61 The problem here is that the image has a non-depth type, but is being sampled as a depth image. This check was added recently to SPIRV-Tools, so we became aware of the problem. As I said, it's not easy in general to decide whether an image is going to be sampled with depth-comparison operators or not. Fortunately the SPIR-V spec allow to mark the depth parameter as unknown (using value 2), so until we come up with something better we use that for all images to please the validator and avoid giving misleading hints to the driver.
-
Arek Hiler authored
-
- Sep 23, 2024
-
-
Giovanni Mascellani authored
Numeric types are used very frequently, and doing a tree search each time one is needed tends to waste a lot of time. I ran the compilation of ~1000 DXBC-TPF shaders randomly taken from my collection and measured the performance using callgrind and the kcachegrind "cycle count" estimation. BEFORE: * 1,764,035,136 cycles * 1,767,948,767 cycles * 1,773,927,734 cycles AFTER: * 1,472,384,755 cycles * 1,469,506,188 cycles * 1,470,191,425 cycles So callgrind would estimate a 16% improvement at least.
-
Giovanni Mascellani authored
vkd3d-shader/spirv: Rewrite vkd3d_spirv_get_type_id_for_data_type() in terms of vkd3d_spirv_get_type_id().
-
Conor McCarthy authored
Enables the bounded range to be mapped to the unbounded one, instead of being mapped to a separate binding which will be populated from the same d3d12 descriptors as the unbounded one.
-
Conor McCarthy authored
tests/d3d12: Test a bounded range at the same offset as an unbounded one in test_unbounded_resource_arrays().
-
Elizabeth Figura authored
If the condition and argument types are compatible, i.e. there is no broadcast, the resulting shape should be the shape of the arguments, not the shape of the condition.
-
Elizabeth Figura authored
Instead of creating a cast node directly. This specifically handles the 1x1 matrix case, which currently the backend code does not expect.
-
Henri Verbeet authored
-
Atharva Nimbalkar authored
-
Henri Verbeet authored
-
Henri Verbeet authored
-
Henri Verbeet authored
-
Henri Verbeet authored
-
Elizabeth Figura authored
-
Elizabeth Figura authored
vkd3d-shader/hlsl: Return an "error" expression when constructing an arithmetic expression from incompatible types.
-
Elizabeth Figura authored
Currently, if an expression successfully parses according to the bison grammar, but for one reason or another cannot generate a meaningful IR instruction, we abort parsing with YYABORT. This includes, for example, an undefined variable or function, invalid swizzle or field reference, or a constructor with a complex or non-numeric data type. Aborting parsing is unfortunate, however, because it means that any further errors in the program cannot be caught by the programmer, increasing the number of times they will need to fix errors and recompile. The idea of this patch is that any such expression will instead generate an IR node whose data type is of HLSL_CLASS_ERROR. Any further expression which would consume an "error" typed instruction will instead immediately return an expression of type "error" (probably the same one) instead of aborting or doing any other type-checking. Currently these "error" instructions should not pass the parsing stage, since hlsl_compile_shader() will immediately notice that compilation has failed and skip any optimization, lowering, or bytecode-writing. A further direction to take this is to pre-allocate one "error" expression immediately when creating the HLSL parser, and return that expression when we fail to allocate an hlsl_ir_node of any type. This means we do not need to handle allocation errors when constructing nodes, saving us quite a lot of error handling (which is not only tedious but currently often broken, if nothing else by virtue of neglecting cleanup of local variables).
-
Elizabeth Figura authored
-
Elizabeth Figura authored
-
Elizabeth Figura authored
-
Elizabeth Figura authored
-
Elizabeth Figura authored
-
Nikolay Sivov authored
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55448 Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Nikolay Sivov authored
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Nikolay Sivov authored
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Nikolay Sivov authored
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
- Sep 20, 2024
-
-
Andrey Gusev authored
-
Nikolay Sivov authored
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-