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>
Restructured text (and markdown) is painful to programatically
manipulate, most python parsers are geared towards writing markdown and
generating html. I'd like to move the calendar updates to being
scripted, as such using csv to store them will be convenient. This also
allows us to simplify our scripting that manipulates the table
considerably.
Acked-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8341>
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>
