- 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>
-
Giovanni Mascellani authored
Currently a descriptor set is represented with a structure whose fields are the various descriptors that the shader is going to use, each of them qualified with its type. This model doesn't match very well what happens with D3D12 and with Vulkan and descriptor indexing and mutable descriptors, where many descriptor of different types can overlap, and only at shader runtime it is decided which of them must be used. Therefore with this patch a descriptor is represented as a structure whose fields carry no intrinsic typing information, but are reinterpreted according to the shader behavior on each access. For the moment there is just one field, but more will be added to account for fancier descriptor types and to workaround Metal limitations. When completed, this design will be similar in spirit to what the Metal shader converter does, with little technical differences. This choice has a couple of drawbacks: 1. shader debugging with Xcode is less comfortable, because the shader doesn't carry static descriptor typing information and Xcode is therefore less able to provide useful context; 2. it requires tier 2 argument buffer support and macOS version >= 13, which includes guarantees on the runtime layout for descriptors. Supporting descriptor indexing and mutable descriptors is considered to be worthy of those drawbacks, though, is effectively required by many applications and appears to be the first goal we should aim for. If needed, in the future we might also add support for older hardware, at least for shaders that do not make use of advanced features.
-