This fixes a performance regression for games (eg. Youngblood) that
declare all images as concurrent. This is likely buggy for compute
queues but this just restores the previous behaviour for now.
Fixes: f4f096805b ("radv: fix TC-compat HTILE images with DST_OPTIMAL on the compute queue")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8351>
It wasn't expected to also enable inside render loops.
Fixes: 4bb92d9145 ("radv: enable TC-compat HTILE in GENERAL on GFX10+")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8351>
This was missing, it can be enabled with RADV_PERFTEST=tccompatcmask.
Note that this feature is still experimental.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8350>
NTT doesn't handle uniforms, and requires them to have been lowered to
UBOs. But for drivers that don't set
nir_shader_compiler_options::lower_uniforms_to_ubo to true, this won't
have happened yet. Neither Zink nor V3D sets this option, and in the
case of Zink this isn't trivial to change.
So let's lower uniforms to UBOs in this case in NTT instead.
Fixes: 03c60762f5 ("gallium/ntt: Fix load_ubo_vec4 buffer index setup.")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4047
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8365>
In order to handle blitting the stencil aspect of a depth-stencil
resource, use aspect-specific pipe formats in the aspect_mask loop.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8340>
When blitting just the stencil aspect, the source and destination
resources are prepared/setup twice. Move the unconditional resource
setup into the aspect_mask loop to avoid this.
In addition, use the aspect provided by the loop instead of the mask
provided by the info parameter.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8340>
Use iris_resource_prepare_texture in iris_blit to avoid partial resolves
for sRGB <-> linear texture views. This affects a trace of L4D2.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8340>
Instead of having a depth-specific assertion in a generic portion of
iris_blit, move it into the depth-specific cases of
iris_resource_texture_aux_usage. Since iris_blit calls that function,
the test still occurs.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8340>
Before this change, iris_blit would prepare the depth buffer in a
depth-stencil resource even when only the stencil aspect was used for the
blit. Use the aspect mask to prepare the correct resource.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8340>
These tests should work, and be built, even if you're only building
gallium drivers.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8353>
The table constructor and the table lookup were doing different things
for big-endian. This fixes MesaFormatsTest.FormatFromFormatAndType and
MesaFormatsTest.FormatMatchesFormatAndType failing to round-trip for
GL_RGBA / GL_SHORT, which we're not currently running in CI for s390x,
but which a subsequent commit will enable.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8353>
Compute the number of components of the destination vector from the
bitsize when eg. a 16-bit vec2 vertex fetches is splitted. This is
because the dst will be a v1, so the p_create_vector should be created
from two v2b fro both sizes to match.
This prevents a regression from the next change which will split
typed vertex buffer loads on GFX6 and GFX10+.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8363>
Not sure why I thought this was correct, but we should consider them for
optimization purposes.
Fixes: ce9205c03b ('nir: add a load/store vectorization pass')
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4202>
There is a path to blit stencil buffers reinterpreting the stencil data
as an RGBA8888 or R8 float texture.
This works fine except for the case when the stencil buffer is
multisampled, and the blit operation needs to resolve it: an average of
the samples is done, which is incorrect, as only one sample must be
used.
This can be observed n the piglit test
`ext_framebuffer_multisample-unaligned-blit 2 stencil downsample -auto
-fbo`, specifically in the triangles border.
To avoid this averaging, let's reinterpret the stencil data as RGBA8888
or R8 uint texture.
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8361>
This assumption becomes incorrect with RADV_PERFTEST=cswave32.
Games include Detroit: Become Human and Doom Eternal.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7918>
Two main reasons:
As described in the previous commit, sending buffers to the Wayland
compositor as quickly as possible effectively results in mailbox
behaviour.
Also, doing the same as for MAILBOX present mode provides the following
benefits:
* We use more images in the swapchain, which avoids stalls on the client
side if the Wayland compositor directly uses the client buffers for
scanout.
* We wait for fences to signal before submitting a new buffer, which
avoids missing frames in the Wayland compositor due to fences not
signalling in time for a flip.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3673
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8197>
This allows Xwayland to forward buffers to the Wayland compositor ASAP
for fullscreen / undecorated windows, which in turn allows true mailbox
behaviour in the Wayland compositor.
Without this, Xwayland has to emulate the mailbox behaviour itself,
which it cannot do as well as the Wayland compositor by design.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8197>
Increase the scope of atomic operations from GPU to system. This is
required for support of SVM to ensure atomic access is maintained for
memory buffers that are not local to the current GPU.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7955>
GV100 code generation uses ATOM instructions for compare-and-swap and
RED instructions for other atomic operations. Make the scope consistent
for both types of operations.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7955>
It didn't do anything useful. GS doesn't use the other user SGPRs.
If we decrease the number of user SGPRs we declare for the GS prolog,
we can remove gfx9_prev_is_vs.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8344>
LLVM expects that exec != 0 when entering loops and generates this code
that becomes an infinite loop if exec == 0:
BB5_1:
vcc_lo = (inverted terminating condition)
s_and_b32 vcc_lo, exec_lo, vcc_lo
s_cbranch_vccnz BB5_3 // jump if vcc != 0 (break statement)
// ... loop body ...
s_branch BB5_1
BB5_3:
For non-monolithic VS before TCS, VS before GS, and TES before GS,
we set exec = (thread enabledmask), which sets 0 for HS-only and GS-only
waves, causing the infinite loop condition above.
Fix it as follows:
- set exec = ~0 at the beginning
- wrap the whole shader (LS and ES) in a conditional block, so that HS-only
and GS-only waves jump over it and never enter such a loop
The TES before GS hang can be reproduced by gfxbench:
testfw_app --gfx egl -w 1920 -h 1080 --gl_api gles -t gl_tess
Fixes: 68d6d097f1 - radeonsi/gfx9: add GFX9 and VEGA10 enums
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8344>
Stencil texture sampling (such as what we have to do for BlitFramebuffer)
is broken with UBWC enabled. We can't just take the
fd_resource_uncompress() path, because that's a blit just like
BlitFramebuffer.
Fixes failure in dEQP-GLES3.functional.fbo.msaa.2_samples.stencil_index8,
but also the uncaught rendering fails of 4_samples.stencil_index8 and
depth24_stencil8.
Prior to "911ce374caf0 freedreno/a6xx: Fix MSAA clear" we would usually
pass and sometimes flake fail on this test occasionally, thus it being
listed as a flake (though the rendering was actually broken). Since that
commit, though, we consistently fail on a pixel of the broken rendering,
and thus this was brought to my attention by the #freedreno-ci channel
spam.
Rob took a look at the performance impact of this, and the worst was maybe
up to .5% fps hit on trex.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8319>
Sync Android.mk GALLIUM_TARGET_DRIVERS names from kmsro meson.build,
notably adding the missing mediatek, meson and rockchip display drivers
names.
It also fixes the imx name into imx-drm as referenced in meson.build
and src/gallium/targets/dri/target.c
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7443>
Like SPIR-V and GL_ARB_sparse_texture2, these return a residency code. It
is placed in the destination after the rest of the result. If it's zero,
then the texel is resident. Otherwise, it's not resident.
Besides the larger destination and the residency code, sparse fetches
work the same as normal fetches.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7774>
These will be useful for sparse texture instructions and image load
intrinsics.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7774>
We already loop n times here, no point in doing n instances as well.
Fixes: e8a40715a8 ("gallium/util: add blitter-support for stencil-fallback")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8301>
Mark the test cases which aren't supported by ir3_parser.y explicitly,
so we notice future regressions. And likewise, fail when we see an
unexpected pass, so we don't forget to update the test vectors in the
future as ir3_parser improves.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8175>
The offset can also be a register, in which case we need to shuffle
around the src order. Add a few more test vectors to cover each
permutation (no offset, immed offset, gpr offset).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8175>
Note that this shows up a slight encoding difference compared to test
vector extracted from blob deqp runs. We think these should be dontcare
bits. For now, add a note and replace the encoded value in the disasm
test.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8175>
Not yet used by the compiler, but needed so we don't loose information
between ir3 parser and instruction encoding.
Currently ignored for cat5, because the uniform vs non-uniform default
is swapped there.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8175>
Add a `.b`.. for the atomic instructions it should be `atomic.b.op` but
for now put the `.b` at the end to simplify life for the existing disasm
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8175>
The blob is using '0' for the low bit in these (except for ldib where it
seems to randomly use either '0' or '1'). The upcoming xml based ISA
spec maps this bit to 'dontcare' in the ldib case.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8175>
Well, really just resinfo.. dealing with the different ldib/stib syntax
for a6xx+ vs earlier seems a bit too painful to deal with. But resinfo
at least gives us some encoding test coverage of this group of instrs.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8175>
This appears to be ignored when writing to predicate registers (which I
guess makes sense, since they are boolean). So no real harm in setting
it, other than it makes some of the ir3_parser test vectors not match
the expected result for encoding.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8175>
Currently ir3 (incl emit_cat5()) expects the samp/tex src register to be
first.. which requires some fixup for the parser to match.
TODO we might want to revisit the src reg order when adding new instr
packing/encoding. For now, lets just make the parser match the rest of
ir3.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8175>
There was some src2 vs src3 confusion, but since the syntax is like:
ldl.f32 rDst, l[rBase+off], ncomp
it makes more sense to call the offset src2 and ncomp src3, than the
way we had it. This is also easier to deal with for the ir3 assembly
parser.
Also, src_offset was only ever used by the assembly parser, and was
handled incorrectly in emit_cat6(), resulting that cat6 load instrs
would not work properly in (for ex) computerator. Since we are
cleaning things up, drop src_offset and make the asm parser work in
the same way as the nir->ir3 frontend.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8175>
Convert everything remaining over to the version which takes # of
register (src + dst) and drop the ir3_instr_create2() version.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8175>
Update the IR and packer to handle the additional cat0 fields, in
prep for adding support in the assembler (in prep for adding round
trip parsing/packing test coverage).
We don't actually use these yet from the ir3 compiler, but at least
this is one less thing to worry about when we start trying to use
them.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8175>
Move out of ir3_parse_asm() so we can re-use it in disasm test for
round-tripping asm/disasm. We don't want failures to be fatal (yet)
as there are still some things missing from the assembler.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8175>
Various things that I noticed which were initially wrong with the xml
based disasm.
These were extracted from a collection of unique instructions extracted
from deqp traces, which unfortunately looses the link back to the
original test case.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8175>
Rhys Perry
James Park
Samuel Pitoiset
Vinson Lee
Erik Faye-Lund
Nanley Chery
Adam Jackson
Juan A. Suarez Romero
Michel Dänzer
Pierre-Eric Pelloux-Prayer
Alistair Popple
Marek Olšák
Eric Anholt
Neil Armstrong
Daniel Schürmann
Rob Clark