- Apr 17, 2025
-
-
Elizabeth Figura authored
This makes the HLSL source easier to read, and makes it easier to convert more functions.
-
- Apr 16, 2025
-
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
That seems to hit a DXC bug we're not interested into.
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
The code doesn't make sense in the first place, even if it's accepted by the compiler, so it makes sense that the behaviour is undefined. And indeed the behaviour is different on AMD (4 is returned), NVIDIA (QNaN is returned) and WARP (device is removed).
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
They do not behave consistently between AMD, NVIDIA and WARP, so there is little point enforcing a specific behaviour.
-
Giovanni Mascellani authored
-
Francisco Casas authored
-
Francisco Casas authored
-
Francisco Casas authored
-
Francisco Casas authored
Currently program errors might result on instructions that use ctx->error_instr as src. In case we hit YYABORT while parsing another part of the HLSL source, we have to make sure that the block that contains the instruction is properly cleaned up, or we might hit the vkd3d:590273:err:hlsl_free_instr Failed assertion: list_empty(&node->uses) assertion when hlsl_ctx_cleanup() is called after the YYABORT. Consider the following shader: float4 main() : sv_target { // Statement A int p = foo; // initializer argument is ERROR. // Statement B undeclared_fun(); // triggers YYABORT. } Statement A will src the ctx->error_instr because of the undeclared identifier and Statement B will trigger an YYABORT because of the undeclared function.
-
Francisco Casas authored
-
Francisco Casas authored
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
It used to be UINT before, but it doesn't make any sense.
-
- Apr 14, 2025
-
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
-
Henri Verbeet authored
-
Giovanni Mascellani authored
vkd3d-shader: Represent resource data types as vkd3d_data_type in struct vkd3d_shader_descriptor_info1.
-
Giovanni Mascellani authored
The stride didn't match the structure size used in the shader. This didn't seem to be a problem on AMD and WARP, but it was on NVIDIA on Windows. Specifically, it seems that the buffer is read using the shader structure size (so most tests pass), but bounds are checked using the buffer stride, so a test returned zero simply because an out-of-bounds read was detected.
-
Giovanni Mascellani authored
Unless the D3D11_FEATURE_DATA_D3D11_OPTIONS2.MapOnDefaultTextures feature is supported, textures with default usage cannot be read by the CPU; and there isn't a need to either, since we're going through a staging texture anyway. This worked on AMD and WARP, but failed on NVIDIA on Windows.
-
Henri Verbeet authored
-
Francisco Casas authored
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57686
-
Francisco Casas authored
-
Elizabeth Figura authored
-
Elizabeth Figura authored
-
Elizabeth Figura authored
-
Elizabeth Figura authored
To match the sysval we set when reading them.
-
Feifan He authored
Co-authored-by:
Giovanni Mascellani <gmascellani@codeweavers.com>
-
Feifan He authored
Co-authored-by:
Giovanni Mascellani <gmascellani@codeweavers.com>
-