- Apr 09, 2025
-
-
Giovanni Mascellani authored
Like we do for GLSL; there's no reason to abort compilation here. Note that this also avoids leaking "gen->buffer" and "gen->string_buffers" on the error path.
-
Shaun Ren authored
-
Shaun Ren authored
-
Shaun Ren authored
vkd3d-shader/tpf: Support SV_RenderTargetArrayIndex/SV_ViewportArrayIndex sysvals in tessellation shaders.
-
Shaun Ren authored
vkd3d-shader/hlsl: Prioritize smaller writemasks for all allocators in allocate_semantic_registers().
-
Shaun Ren authored
-
Shaun Ren authored
-
- Apr 08, 2025
-
-
Henri Verbeet authored
So that they can be used for e.g. Wayland or macOS support. Or Windows, if we're so inclined.
-
Henri Verbeet authored
These were used for demo_load_shader(), but that was removed some time ago in commit aa5d48ee.
-
Victor Chiletto authored
-
Victor Chiletto authored
Try parsing first as integer, and if the parse stops at a decimal separator, parse as float.
-
Victor Chiletto authored
-
navi authored
-
navi authored
-
- Apr 03, 2025
-
-
Elizabeth Figura authored
-
Elizabeth Figura authored
-
Giovanni Mascellani authored
Technically it is not, the Vulkan commands we're generating are still not correct. But let's get rid of the failure message.
-
Giovanni Mascellani authored
With this we can finally disallow failure for the macOS CI script, which is more valuable than checking DXC. Eventually DXC tests will have to be fixed, though.
-
Giovanni Mascellani authored
It's hard to pinpoint exactly what's going wrong with these tests. They seem to be related to atomics and GPU timestamps, both categories that are known to have problems on MoltenVK in a way or another; those failures clearly depend on a few factors like the MoltenVK version, the macOS version and whether we're in a virtual machine or not, but the exact dependency on those factors is hard to describe (for example, in general the paravirtualized device offered inside virtual machines has a lot more problems than real devices, but I've seen tests, fixed all other conditions, working on the paravirtualized device and not on the real device). The only thing all tests in this batch have in common is that I've never seen them fail on a Sequoia system, thus I've settled for using just that as the bug_if() condition. Ultimately, wasting a lot of time to get to the bottom of each single test failure is pointless, and being able to mark the CI job as not allowed to fail gives better regression protection than investigating each of those. Also, I routinely run the tests on a Sequoia system, so if these tests get broken this is going to be noticed anyway.
-
- Apr 02, 2025
-
-
Nikolay Sivov authored
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Nikolay Sivov authored
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
Elizabeth Figura authored
-
Elizabeth Figura authored
-
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
-