The upstream kernel supported everything needed to stop doing
kernel-side relocs before the first things with a6xx were fully
supported in upstream kernel. Take advantage to drop some extra
overhead in OUT_RELOC() and equiv in the pack macros.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18646>
The struct body was originally hidden to avoid it being part of the ABI
between libdrm_freedreno and mesa. But that is no longer a problem.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18646>
The current stack size is a significant limiter for occupancy, and
hence we need smaller stacks in LDS.
Rhys earlier had a patch that just put the N entries closest to the
root in LDS and the rest in scratch. However, this is not ideal for
performance as most of the activity is happening away from the root,
near the leaves. Of course we can't just switch it around, as the
leaf activity likely isn't happening all the way at the end of the
stack.
So what we do is make the LDS stack kinda a ringbuffer by always
accessing it using the stack index modulo the buffer size (always
a power of two so we can efficiently mask). If we then do not have
free space in this buffer we evict the entries closest to the root
to scratch and if we hit the "bottom" of the LDS space we load from
scratch.
Some rough perf numbers for indication with Q2RTX:
| evicting | LDS entries | perf |
|----------|-------------|------|
| no | 76 | 55% |
| no | 32 | 100% |
| no | 24 | 105% |
| yes | 32 | 95% |
| yes | 16 | 100% |
| yes | 8 | 90% |
| yes | 4 | 75% |
(For the case with 4 entries we need to do some extra accounting as
a full batch may not be available to evict)
So an obvious choice is to use a stack of 16 entries.
One might wonder if Q2RTX perf is mainly good due to BVHs with very
little geometry and hence low depth, so I also did some profiling
with control. This is done with RGP instruction timing, so this is
instructions executed not weighted for enabled masks, i.e. divergence
effects included.
| game | LDS entries | scratch action | fraction of iterations |
|---------|-------------|----------------|------------------------|
| Control | 8 | store | 10.3% |
| Control | 8 | load | 34.8% |
| Control | 16 | store | 0.58% |
| Control | 16 | load | 2.62% |
| Q2RTX | 16 | store | 1.00% |
| Q2RTX | 16 | load | 3.07% |
So Q2RTX doesn't seem like an unreasonably good case for this
algorithm.
On the implementation side, we can always place the scratch stack at
address 0 by just reserving the scratch space, and in the case of fixed
callstack size moving that up. In the dynamic case the dynamic stack
base already takes any reserved scratch space into account.
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18541>
This reverts commit 3750663c72.
Doing things with derefs adds extra instructions for multiplying the
index with the element size, e.g.
BBF0_13:
s_waitcnt vmcnt(0)
v_mov_b32_e32 v27, v55
s_mov_b32 s23, exec_lo
v_cmpx_ne_i32_e32 -1, v27
s_cbranch_execz _L14
BBF0_14:
v_lshlrev_b32_e32 v48, 2, v46 <--
ds_write_b32 v48, v27
v_add_nc_u32_e32 v46, 32, v46
_L14:
s_mov_b32 exec_lo, s23
v_mov_b32_e32 v27, v54
s_mov_b32 s23, exec_lo
v_cmpx_ne_i32_e32 -1, v27
s_cbranch_execz _L15
BBF0_15:
v_lshlrev_b32_e32 v48, 2, v46 <--
ds_write_b32 v48, v27
v_add_nc_u32_e32 v46, 32, v46
On Q2RTC indirect lighting this saves about 2.3 VALU instructions
per loop iteration, which is ~4% of VALU instructions (we're at
58 per iteration now according to RGP).
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18538>
Saves a bunch of processing and a lot of LDS traffic.
Improves perf of the indirect lighting RT pass in Q2RTX by ~3%. This
is mostly due to the -5% VALU instructions and -25% LDS instructions.
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18538>
Only used in debug builds.
Signed-off-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18643>
Only used in debug builds.
Signed-off-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18643>
there's no requirement in the spec that the geometry for resolves must match,
only that the geometry must be positive (i.e., no flipped extents)
this avoids major perf issues for scaled resolves
cc: mesa-stable
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18364>
reads flags field from CurrPic struct in pps for VA_PICTURE_H264_LONG_TERM_REFERENCE. If found, Curr_pic.frame_idx wil be used for the long term reference index
In get_picture_storage, check if current frame is ltr, and whether its ref frame is ltr.
In radeon_enc_slice_header, adds the ref_pic_list_modification_flag_l0 and long_term_reference_flag for ltr
v2: fix code formatting issues
Reviewed-by: Ruijing Dong ruijing.dong@amd.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18219>
This duplicates the lowering from nir_lower_packing. However, nir_lower_packing
also lowers a pile of other instructions that we do implement natively, and this
is easier than adding a bunch of knobs to nir_lower_packing to get just what we
need.
Fixes test-printf address_space_4.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
Implement like other workgroup barriers. No subgroup barriers yet, but that
doesn't seem needed yet.
Fixes test_basic.async_copy_global_to_local and a pile of other OpenCL tests.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
Array index always goes in the fourth 16-bit component on Valhall. I'm unsure
whether that should also apply to Bifrost. f256ec2a88 ("pan/bi: Fix 1DArray
image coordinate retrieval") says that it should be in the third component on
Bifrost, but I can't remember why that would be the case.
Fixes OpenCL test image_streams.write.1darray on Valhall.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
Works around LLVM/SPIR-V stupidity. In effect this means we always use typeless
image stores, which is good enough for both CL and GL.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
Scalarizing phis results in vector constructions (nir_op_vec) of the same size
as the phi, so a wide phi (>128-bit) will result in a wide vector op that the
backend can't handle. These wide vector ops can always be copypropped away, but
that relies on running NIR copy/prop after scalarizing phis, which was not
always happening before. By scalarizing phis before the opt loop instead of
after, we guarantee that copyprop and DCE run to completion and we get
appropriately lowered code in the backend.
Fixes parts of integer_ops.integer_divideAssign with longs.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
Fixes test_bruteforce.isnormal. We don't implement fisnormal in the backend, but
actually lower_bool_to_bitsize was failing earlier since there's no fisnormal32
to lower to either.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
While we have a POPCOUNT.i32 instruction, we do not have v2i16/v4i8 variants.
The code generated by lower_to_bitsize doesn't seem any better than what we
could do ourselves, so let's use that.
While we're at it, give bitfield_reverse the same treatment as we have only
BITREV.i32. I don't think we can get <32-bit bitfield_reverse in either GL or
CL, but that seems likely to change in the future. (It looks to be valid SPIR-V,
at least.)
Fixes integer_ops.popcount.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18656>
Rob Clark
Bas Nieuwenhuizen
Rhys Perry
Dave Airlie
Mike Blumenkrantz
Kai Wasserbäch
Kuixi Ren
Alyssa Rosenzweig