- Apr 02, 2025
-
-
Francisco Casas authored
Every call to shader_instruction_array_insert_at() means a possible reallocation of all vsir instructions in the program. This means that all previous pointers are potentially no longer valid. We are currently using these potentially invalid pointers in some cases, usually in the form of "ins->location". This commit fixes these. I moved all pointer changes to right after the call to shader_instruction_array_insert_at() to make this more evident.
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
-
Shaun Ren authored
-
Shaun Ren authored
vkd3d-shader/hlsl: Ensure that uniform objects are never written to in copy_propagation_transform_object_load().
-
Shaun Ren authored
The following pixel shader currently triggers an infinite loop during copy propagation, which is fixed by this commit: sampler s; Texture2D t1, t2; float4 main() : sv_target { Texture2D t = t1; t1 = t2; t2 = t; return t1.Sample(s, float2(0, 0)) + t2.Sample(s, float2(0, 0)); } The infinite loop occurs because copy_propagation_transform_object_load() replaces t1 in the resource_load(t1, ...) instruction with t2, t1, t2, ... repeatedly.
-
Francisco Casas authored
Note that we still have to preempt the propagation to SM1 pixel shader uniforms. Otherwise this will turn the many constant derefs that appear from the <index-val> copy generated in lower_index_loads() into a single non-constant deref, causing it to allocate all the registers instead of up until the last one used.
-
Francisco Casas authored
-
Francisco Casas authored
-
Francisco Casas authored
Some SM1 src registers have idx_count = 0, in which case we have to respect that instead of always reading reg->reg.idx[0].offset even when it is invalid.
-
Francisco Casas authored
Here, a vertex shader version of the previous test by Shaun is introduced. Note that in this case the uniform allocates all 4 registers instead of 3 because it is indirectly addressed.
-
Francisco Casas authored
Note that, for indexes with a decimal part, the behavior is different depending on whether it is a temp load or a direct uniform load (which can only happen on vertex shaders). The former rounds to the closest-to-zero, while the latter rounds to the nearest even.
-
Elizabeth Figura authored
-
Elizabeth Figura authored
-
Elizabeth Figura authored
-
Elizabeth Figura authored
-
Elizabeth Figura 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.
-