- Mar 28, 2025
-
-
Co-authored-by:
Giovanni Mascellani <gmascellani@codeweavers.com>
-
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.
-
Co-authored-by:
Giovanni Mascellani <gmascellani@codeweavers.com>
-
Giovanni Mascellani authored
They're not supported by the shader runner anyway, but there's no reason to make the code subtly wrong.
-
- Mar 21, 2025
-
-
Giovanni Mascellani authored
-
- Mar 19, 2025
-
-
Henri Verbeet authored
-
- Mar 18, 2025
-
-
Nikolay Sivov authored
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Giovanni Mascellani authored
On MoltenVK it seems that all draws are always executed, independently of the early depth stencil test. The problem doesn't seem to belong to vkd3d or MoltenVK, because the generated Metal commands look correct. I tried looking at a GPU capture with Xcode, which was not very conclusive because it doesn't state clearly whether early fragment tests were passed or not. Sometimes it says that a fragment shader execution had no thread execution data, which I interpret as the early fragment tests having prevented the fragment shader from running, but it's not really consistent, and it's never clear which results are based on software simulation and which on the hardware run. However taking everything into account I think the most likely explanation is some incorrect optimization at the Metal level.
-
Giovanni Mascellani authored
The graphics pipeline triggers an internal error in the Metal pipeline compiler, with a completely generic error message. I have no idea what the actual problem is.
-
Shaun Ren authored
-
Shaun Ren authored
-
Shaun Ren authored
-
Shaun Ren authored
-
Shaun Ren authored
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
There is no need, and it only complicates tracking ownership.
-
Giovanni Mascellani authored
They are already available through the program.
-
Giovanni Mascellani authored
So it doesn't have to be passed around uselessly.
-
Giovanni Mascellani authored
This makes it more similar to the MSL and GLSL generators. It also looks like a cleaner design, the backend is supposed to get access to the vsir program after it has gone through the pipeline.
-
Francisco Casas authored
-
Francisco Casas authored
These bitwise operations are not available in these profiles.
-
Francisco Casas authored
Similarly to the modulus operator, d3dbc results with constant folding are different from results when constant folding cannot be applied, and different from tpf results.
-
Francisco Casas authored
Note that in d3dbc target profiles it gives different results when this operation is constant folded compared to when it is not. This suggests that whatever pass lowers the modulus operation to d3dbc operations doesn't do it before constant folding. Also note that when constant folded, d3dbc results differ from tpf results for negative operands, because of the loss of precision that happens when NEG is constant folded. So the same integer modulus expression can have 3 different results depending on the context.
-
Francisco Casas authored
-
Elizabeth Figura authored
-
- Mar 17, 2025
-
-
Giovanni Mascellani authored
As far as I know there is no way to implement this properly on Vulkan, and all the other Vulkan implementations essentially work by luck. In Vulkan the initial layout of a resource must always be UNDEFINED or PREINITIALIZED and it must be transitioned away from before any meaningful use of that image is done. Therefore it's possible to alias two images and let the second one inherit the content in the first one only if both already exist (and are in the same layout) before the first writing is done. If, as in this example, the second image is created after the first one has already been written to, the obligatory transition away from UNDEFINED or PREINITIALIZED will potentially wipe out the content. Therefore I am marking this as todo, not as a bug. I might also be that there is a bug in MoltenVK, and ultimately that's the reason why we're reading invalid data, but technically the Vulkan commands we generate are incorrect anyway.
-
Giovanni Mascellani authored
When textures[1] is read for the second time it is aliased to textures[0]. But textures[0] was left in COPY_DEST state (since its creation), and textures[1] is currently recreated in COPY_SOURCE state, which AFAIU is invalid. So recreate textures[1] in COPY_DEST state and then transition it before reading it.
-
Giovanni Mascellani authored
I haven't investigated the actual problem here, but the generated Vulkan commands look correct (and work with basically all other Vulkan implementations) and MoltenVK is known to have incomplete tessellation support, so it's likely that the problem is there.
-
Giovanni Mascellani authored
Similarly to 5d4edba9, it seems that sometimes MoltenVK returns 0 to timestamp queries. It doesn't happen deterministically and it might depend on the hardware (I have seen differences between the M2 I used some time ago and the M3 Max I have now).
-
Giovanni Mascellani authored
Essentially to make d3d12.log more readable.
-
Henri Verbeet authored
It uses dxcompiler_create(), which (potentially) uses dlopen().
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
-
Henri Verbeet authored
-
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>
-
Nikolay Sivov authored
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-