This commit moves the calculation of tri_bary out of
brw_nir_rt_load_mem_hit_from_addr(), and only do the calculation on
demand, since unorm_float_convert can be expensive. We do this for both
Xe1/2 and Xe3+ for consistency.
Signed-off-by: Kevin Chuang <kaiwenjon23@gmail.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33047>
For Xe3+, the upper 8 bits of the second dword of a potential hit is
used to store hitGroupIndex0, which is stuffed by the HW. This
hitGroupIndex0 will later be used by the HW again to reconstruct the
whole hitGroupIndex when driver issues a TRACE_RAY_COMMIT.
We were corrupting this hitGroupIndex0 at the driver by setting the
whole dword to hit_kind, which will cause the HW to read a wrong
hitGroupIndex and therefore invoke a wrong closest hit shader. The
behavior can be seen in
dEQP-VK.ray_tracing_pipeline.pipeline_no_null_shaders_flag.gpu.boxes.\*
and dEQP-VK.ray_tracing_pipeline.pipeline_library.configurations.\*
This commit changes the driver to only use lower 24bits to store the
hit_kind, and leave the upper 8bits as it.
Signed-off-by: Kevin Chuang <kaiwenjon23@gmail.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33047>
This will help us to handle code path separately for Xe3+ for updated
64bit memory data structure for RT.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Kevin Chuang <kaiwenjon23@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33047>
On v12+, the hardware report support for 8 levels but
effectively only support up to 4 levels.
In case more than 4 levels are used, it will default to 0xAA when
tile_size is 32x32 or lower, otherwise 0xAC when the tile_size is greater than 32x32.
This patch makes it that we now ensure that the bins can fit inside out
tiler budget and otherwise drop levels until it fit.
This also allows the hardware to decide the hierarchy on v12+
if we know it will fit.
This fixes "dEQP-GLES31.functional.fbo.no_attachments.maximums.all" and
dEQP-GLES31.functional.fbo.no_attachments.maximums.size" on v12+ but
also likely more if we were exhausting the memory budget.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Backport-to: 25.1
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34559>
clang 20 complains:
../src/amd/compiler/aco_assembler.cpp:837:28: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
837 | vaddr[num_vaddr + i] = reg(ctx, instr->operands.back(), 8) + i + 1;
| ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/amd/compiler/aco_assembler.cpp:832:12: note: at offset 5 into destination object ‘vaddr’ of size 5
832 | uint8_t vaddr[5] = {0, 0, 0, 0, 0};
| ^~~~~
../src/amd/compiler/aco_assembler.cpp:837:28: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
837 | vaddr[num_vaddr + i] = reg(ctx, instr->operands.back(), 8) + i + 1;
| ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/amd/compiler/aco_assembler.cpp:832:12: note: at offset 6 into destination object ‘vaddr’ of size 5
832 | uint8_t vaddr[5] = {0, 0, 0, 0, 0};
| ^~~~~
../src/amd/compiler/aco_assembler.cpp:837:28: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
837 | vaddr[num_vaddr + i] = reg(ctx, instr->operands.back(), 8) + i + 1;
| ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/amd/compiler/aco_assembler.cpp:832:12: note: at offset 7 into destination object ‘vaddr’ of size 5
832 | uint8_t vaddr[5] = {0, 0, 0, 0, 0};
| ^~~~~
But `i < MIN2(instr->operands.back().size() - 1, 5 - num_vaddr)` means `i` is
at most `5 - num_vaddr - 1`, which means `vaddr[num_vaddr + i]` =>
`vaddr[num_vaddr + 5 - num_vaddr - 1]` => `vaddr[5 - 1]` => `vaddr[4]` which
is within the valid indices.
For some reason, using signed `int` instead allows clang to figure this
out, so let's do that since we don't need the extra range.
While at it, use ARRAY_SIZE(vaddr) instead of hard-coding the same `5`
in several places.
Backport-to: 25.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34625>
With H264 the target surface can also be in the reference list for
current frame, so it can only be inserted into the DPB list after
iterating over all references.
Fixes: 0e68a2655f ("radeonsi/vcn: Rework decode ref handling")
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34527>
For some reason, shfl doesn't seem to like rZ. I have no idea why but
shfl.up pt, r5, r5, r3, 0x0
works fine but
shfl.up pt, r5, r5, r3, rz
does not. Fortunately, this is pretty easy to handle in the generator
by just using `as_u32()` instead of the AluSrc hack I did before.
Fixes: 608eef01d6 ("nak/sm20: Add subgroup ops")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34624>
No change in the size on GPUs with 16 CUs per SE such as Navi31 and Navi48.
Navi21 and Navi32 get 25% increase. (20 CUs per SE)
APUs get a significant decrease. For example:
- Phoenix gets 25% decrease
- Vangogh gets 50% decrease
- Phoenix2 gets 75% decrease
- Raphael and Stoney get 87.5% decrease
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34544>
When VMMs do not support VIRTGPU_DRM_CAPSET_VENUS the capset data
remains zeroed. By requiring the stable wire_format_version 1 this can
be detected early without initialising the renderer.
Avoids triggering `assert(capset->supports_blob_id_0);` in debug builds
under such circumstances.
Cc: mesa-stable
Signed-off-by: Janne Grunau <j@jannau.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34613>
Add queue id support to the user queue wait IOCTL
drm_amdgpu_userq_wait structure.
This is required to retrieve the wait user queue and maintain
the fence driver references in it so that the user queue in
the same context releases their reference to the fence drivers
at some point before queue destruction.
Otherwise, we would gather those references until we
don't have any more space left and crash.
Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Suggested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34493>
