This decreases the time spent in amdgpu_cs_submit_ib from 15.4% to 8.3%
in VP2020/Catia1, which is a decrease of CPU load for that thread by 46%.
Overall, it increases performance by a small number in CPU-bound benchmarks.
The biggest improvement I have seen is VP2020/Catia2, where it increases
FPS by 12%.
It no longer stores pipe_fence_handle references inside amdgpu_winsys_bo.
The idea is to have a global fixed list of queues (only 1 queue per IP
for now) where each queue generates its own sequence numbers (generated
by the winsys, not the kernel). Each queue also has a ring of fences.
The sequence numbers are used as indices into the ring of fences, which
is how sequence numbers are converted to fences.
With that, each BO only has to keep a list of sequence numbers, 1 for each
queue. The maximum number of queues is set to 6. Since the system can
handle integer wraparounds of sequence numbers correctly, we only need
16-bit sequence numbers in BOs to have accurate busyness tracking. Thus,
each BO uses only 12 bytes to represent all its fences for all queues.
There is also a 1-byte bitmask saying which sequence numbers are
initialized.
amdgpu_winsys.h contains the complete description. It has several
limitations that exist to minimize the memory footprint and updating of
BO fences.
Acked-by: Yogesh Mohan Marimuthu <yogesh.mohanmarimuthu@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26643>
We would compute the unique IDs for 1000 slab entries and then only use
a few, wasting the IDs. Assign the IDs only when we actually need to
return a new buffer.
This decreases the number of collisions we get in amdgpu_lookup_buffer,
and thus the number of times we have to search in the BO list.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26643>
The buffer pointer is always at a constant offset from pb_cache_entry,
so just pass the "offsetof" value to pb_cache and use that to get
the pointer.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26643>
Keep it only in amdgpu_bo_real and amdgpu_bo_sparse. Slab entries can
compute it from the slab BO and adding their entry index.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26643>
The pb_slab pointer can be used to get the BO pointer because pb_slab is
inside the BO structure now.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26643>
Add contents of amdgpu_bo_slab into it. This will allow removing the "real"
pointer from amdgpu_bo_slab_entry because "(char*)entry.slab" is now
pointing next to it.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26643>
This increases FPS in VP2020/Catia1 by 10-18%!!!!!!!!!!!!!!!!!!!!!!!
I have no rational explanation for this.
In the most extreme case, 8192 256B slab BOs (smallest size) are now
allocated from a single 2MB slab.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26643>
Since the radeon winsys implements fences as buffers, we need radeon_winsys*
to destroy them. This will enable the removal of pb_cache_entry::mgr.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26643>
to decrease pb_cache_entry by 8 bytes.
Add msecs_base_time to offset time == 0 to the creation of pb_cache.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26643>
INTEL_NEEDS_WA macros are valid when a workaround applies to all
platforms which have the GFX_VERx10 versions for the workaround.
Some workarounds were fixed at a stepping after the platform release.
If a workaround applies partially to any platform, then GFX_VERx10
cannot be used to correctly apply the workaround.
This change invalidates INTEL_NEEDS_WA_16014538804 and
INTEL_NEEDS_WA_22014412737, which were fixed for MTL platforms at
stepping b0. The run-time checks were already present for all uses of
these macros. Updating the poisoned macros to INTEL_WA_{num}_GFX_VER
compiles out the run-time checks on platforms where they cannot apply.
Acked-by: Caio Oliveira <caio.oliveira@intel.com>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26898>
Fix piglit.spec@ext_image_dma_buf_import@ext_image_dma_buf_import-modifiers
randomly skipping some tests as external_only content was never initialized.
Cc: mesa-stable
Reviewed-by: default avatarMike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26305>
zink_bo_create can run into a heap-use-after-free when the bo is still
referencing an batch_state from an older destroyed context. In order to
fix this, every context gives back their batch_states to the zink, where
they can be reused from for new contexts.
Cc: mesa-stable
Suggested-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26889>
This is safe to do in all circumstances due to the age of the hardware.
(we don't have UBOs, just constant registers with automatic OOB checks)
R500 hardware doesn't have standard adress register in fragment shaders
and while we have the loop register which we in theory can use for indirect
access, this is currently not possible to wire through NIR. So anytime
there is an indirect uniform array access in a loop, we end with a if
ladder with size depending on the size of the uniform array. The two worst
behaving apps here are glamor and some GTK shaders, both of which are
sometimes ending over the 512 instructions limit. Flattening the if
ladders helps a LOT, so we can get into the instruction limit in most
cases (all glamor shaders are OK now). So just enable the flattening by
setting all load_ubo_vec4 with ACCESS_CAN_SPECULATE.
Shader-db RV530:
total instructions in shared programs: 128762 -> 128440 (-0.25%)
instructions in affected programs: 540 -> 218 (-59.63%)
helped: 3
HURT: 0
total temps in shared programs: 17543 -> 17550 (0.04%)
temps in affected programs: 11 -> 18 (63.64%)
helped: 0
HURT: 3
total cycles in shared programs: 196984 -> 196657 (-0.17%)
cycles in affected programs: 592 -> 265 (-55.24%)
helped: 3
HURT: 0
LOST: 0
GAINED: 7
No changes for R300/R400 because there we don't have control flow
anyway.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6366
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26877>
The fcsel lowering for R3xx happens already in the main loop, here we
only do it for the fcsel_ge that comes from the frunc.
No change in shader-db
Reviewed-by: Filip Gawin <filip.gawin@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26816>
