We use SHADER_OPCODE_SEND directly instead of FS_OPCODE_FB_WRITE (for a
while now) and FS_OPCODE_REP_FB_WRITE (since the previous commit).
Assert that it isn't used on Gfx7+.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20172>
Sandybridge uses this code and needs MRFs, but all other platforms send
from GRFs. Do that directly rather than relying on the MRF hack.
Ivybridge and later also use SHADER_OPCODE_SEND directly rather than
a virtual opcode that's handled in the generator, so we follow suit.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20172>
We never set key->clamp_fragment_color when compiling the BLORP fast
clear shaders. Besides, we were setting saturate on an FB write opcode,
which...isn't even a thing. We would need it on the MOV, and weren't
setting it there. So it wouldn't have even worked.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20172>
This is basically just once through the loop but copy and pasted. One
difference is that the single render target case used a headerless
message, and the multiple render target case always used headers.
Now we use headerless messages for the first render target, even in the
multiple render target case. While we already have it set up for the
other RTs, it's still 2 fewer registers to send. Minor improvement.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20172>
A long time ago, we used a uniform for the clear color. Back in 2014,
we added support for using a flat input instead, as this was easier for
Vulkan, but we left the option of using a uniform for OpenGL.
Eventually nobody used the uniform approach anymore, but the compiler
code to handle it remained. Drop the dead code.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20172>
This code is compiled out, but has been left in place in case we wanted
to use it for debugging something. In the olden days, we'd use it for
platform enabling. I can't think of the last time we did that, though.
I also used to use it for debugging. If something was misrendering, I'd
iterate through shaders 0..N, replacing them with "draw hot pink" until
whatever shader was drawing the bad stuff was brightly illuminated.
Once it was identified, I'd start investigating that shader.
These days, we have frameretrace and renderdoc which are like, actual
tools that let you highlight draws and replace shaders. So we don't
need to resort iterative driver hacks anymore. Again, I can't think of
the last time I actually did that.
So, this code is basically just dead. And it's using legacy MRF paths,
which we could update...or we could just delete it.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20172>
We can end up in situation where we are dispatched with a multisample
framebuffer but not at per-sample. In this case we would request the
at_sample value with the wrong message configuration.
Relying on the BRW_WM_MSAA_FLAG_MULTISAMPLE_FBO flag superseeds
BRW_WM_MSAA_FLAG_PERSAMPLE_DISPATCH.
Fixes piglit tests :
spec@arb_gpu_shader5@arb_gpu_shader5-interpolateatsample*
With Zink on Anv
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 68027bd38e ("intel/fs: implement dynamic interpolation mode for dynamic persample shaders")
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25854>
While the fs_visitor::validate() implementation is empty in release
build, we still emit calls to it since it is defined in a separate
compilation unit than its callers. To fix this, just expose an inline
empty function in the header for the release mode.
Fossil run time differences in TGL laptop (difference at 95.0% confidence):
```
Rise of The Tomb Rider (Native) [n=7]
-0.482857 +/- 0.010932
-1.60608% +/- 0.0363621%
Cyberpunk 2077 (DXVK) [n=7]
-0.987143 +/- 0.0904516
-0.82996% +/- 0.076049%
Batman Arkham City (DXVK) [n=7]
-7.74857 +/- 0.329561
-1.46298% +/- 0.0622231%
```
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25847>
There is not real need to use the spirv-linker here at all,
we can just read all the CL C files into one buffer, then compile
that buffer in a single pass.
This worksaround an issue seen with llvm17 and opaque pointers
and the spirv linker.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25759>
First, we need to give the parent_instr field a unique name to be able to
replace with a helper. We have parent_instr fields for both nir_src and
nir_def, so let's rename nir_src::parent_instr in preparation for rework.
This was done with a combination of sed and manual fix-ups.
Then we use semantic patches plus manual fixups:
@@
expression s;
@@
-s->renamed_parent_instr
+nir_src_parent_instr(s)
@@
expression s;
@@
-s.renamed_parent_instr
+nir_src_parent_instr(&s)
@@
expression s;
@@
-s->parent_if
+nir_src_parent_if(s)
@@
expression s;
@@
-s.renamed_parent_if
+nir_src_parent_if(&s)
@@
expression s;
@@
-s->is_if
+nir_src_is_if(s)
@@
expression s;
@@
-s.is_if
+nir_src_is_if(&s)
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24671>
While working on cooperative matrix support, I noticed some invalid
DP4A instructions being generated.
dp4a(32) g33<1>UD g21<8,8,1>UD g1.0<0,1,0>UD g9<1,1,1>UD
This violates the constraint that the destination or a source can only
access two consecutive GRFs.
I'm a little surprised that validation didn't catch this. Perhaps
because it's a 3 source instruction? Either way, it seems like a bigger
project to fix that.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Fixes: 0f809dbf40 ("intel/compiler: Basic support for DP4A instruction")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25554>
In the default case, there's a special case with a few conditions.
Prefer the cheapest conditions first, so we can take advantage of
short-circuiting.
Effect is a small but still significant reduce in shader compilation
times, as can be seen by:
- Fossil replay for Rise of the Tomb Raider
```
Difference at 95.0% confidence
-0.433333 +/- 0.028609
-1.42556% +/- 0.0941163%
(Student's t, pooled s = 0.0337886)
```
- Fossil replay for Batman Arkham City
```
Difference at 95.0% confidence
-8.84 +/- 0.146083
-1.65932% +/- 0.0274207%
(Student's t, pooled s = 0.125423)
```
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25549>
SIMD1 instructions are problematic because they are considered partial
writes. This increases the liveness of the destination register
written by those instructions. To workaround this we use UNDEF
instructions to bound the liveness of the register. But this causing
other issues like in this case :
undef(1) vgrf2
mov(1) vgrf2, u4.0
add(1) vgrf3, vgrf2.0, 64UD
In this case the copy propagation pass in unable to see that vgrf2 in
the add() instruction can be replaced with the uniform u4.0.
To fix this problem, we switch NoMask SIMD8 instructions that cover
the entire register. We can drop the UNDEF instructions and now copy
propagation can do its job.
Good results on 2 apps :
Cyberpunk 2077 :
Totals from 7258 (68.80% of 10549) affected shaders:
Instrs: 6332210 -> 6073833 (-4.08%); split: -4.11%, +0.03%
Cycles: 130667501 -> 127351268 (-2.54%); split: -3.12%, +0.58%
Subgroup size: 90320 -> 90400 (+0.09%)
Spill count: 90 -> 68 (-24.44%)
Fill count: 82 -> 64 (-21.95%)
Scratch Memory Size: 8192 -> 6144 (-25.00%)
Max live registers: 385464 -> 375152 (-2.68%)
Max dispatch width: 64336 -> 64424 (+0.14%); split: +0.96%, -0.82%
Gaining 60 SIMD16/SIMD32 shaders, loosing 33
Strange Brigade :
Totals from 2137 (53.12% of 4023) affected shaders:
Instrs: 1544031 -> 1457544 (-5.60%); split: -5.60%, +0.00%
Cycles: 22292564 -> 21868978 (-1.90%); split: -2.43%, +0.53%
Subgroup size: 25328 -> 25344 (+0.06%)
Max live registers: 113716 -> 111214 (-2.20%)
Max dispatch width: 17232 -> 18608 (+7.99%); split: +8.36%, -0.37%
Gaining 138 SIMD16/SIMD32 shaders, loosing 4
On app slightly negatively affected :
Dota2 :
Totals from 232 (14.73% of 1575) affected shaders:
Instrs: 30029 -> 28194 (-6.11%)
Cycles: 385155 -> 371422 (-3.57%); split: -3.59%, +0.02%
Max live registers: 6792 -> 6780 (-0.18%)
Max dispatch width: 2256 -> 2160 (-4.26%)
Loosing 6 SIMD32 shaders
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24554>
Some recent NIR changes started generated those instructions. We need
to handle them to be able to rematerialize.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24554>
This is what most logical SEND messages do when they take a variable
number of components. 'inst->mlen' is expected to be zero for logical
SEND opcodes, which are expected to behave like plain arithmetic
operations, so certain automated transformations (like SIMD lowering)
can manipulate them without opcode-specific special-casing.
Guessing the number of components from 'inst->mlen' has other
disadvantages, because it requires duplicating the logic that infers
the message payload size in every use of the instruction -- Instead we
can just do the computation once during logical send lowering. In
addition on LNL platform this causes the 'inst->mlen' field of URB
writes to have units inconsistent with every other SEND instruction,
which is likely to lead to confusion and bugs down the road.
Rework:
* Marcin: update emit_urb_indirect_vec4_write
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25195>
v2: Account for 512b physical registers which causes the URB handle to be in FIXED_GFR 2 instead of 1.
XXX - Use fs_builder::vgrf() instead of open-coded dispatch_width calculations.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25195>
Rework:
* Sqaushed in changes Marcin Ślusarz's patches:
* "intel/compiler: skip adding 0 to payload address"
* "intel/compiler/xe2: drop masking off top 8 bits of URB handle"
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25195>
Those are used in the failure paths and are easily retriavable from the
stage itself, so no need to store them.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25367>
The position in the error array already indicate the SIMD in question,
so take off all the formatted printing from the errors -- which in some
cases were just not needed. We lose a little bit of extra context but
it is all easily derivable from the message and the SIMD.
This also will remove the overhead when SIMD selection is being used to
just to find the selected dispatch width -- at a point where the shaders
were already compiled -- and the errors are not used at all.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9849
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25336>
