summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/stackcollapse.py
diff options
context:
space:
mode:
authorNicholas Kazlauskas <nicholas.kazlauskas@amd.com>2025-08-26 17:12:44 -0400
committerAlex Deucher <alexander.deucher@amd.com>2025-10-13 14:14:32 -0400
commit8e8691ecee8239634dd9a5f87655fba9bb1ee874 (patch)
treebae98a18e00bb82981c9b31983e114c8a5fde486 /tools/perf/scripts/python/stackcollapse.py
parentc58d6b1d98db30a523b3b4d052ef764e503a4c34 (diff)
drm/amd/display: Driver implementation for cursor offloading to DMU
[Why] We require an interlock between driver and firmware for upcoming features and given that this could possibly happen on any single cursor programming call (and that we can't asynchronously wait for firmware to respond because of it) we'd be regressing cursor performance by at least an extra 40us per call. When we could possibly have cursor update every 20us - 100s from high frequency gaming mice this means that we'd be stuttering or dropping updates and impacting overall cursor performance. We want a solution that can: 1. Interlock between other firmware features 2. Not stall out or require the DMCUB lock for every single update [How] When cursor offloading is enabled and supported by an ASIC driver will route the cursor programming through to DMU as part of the regular DC stream cursor programming interfaces for attributes and position. The atomic pipe programming version will not be updated: this will still follow the existing programming path by keeping track of a field that specifies when the register writes should be deferred to DMU. Cursor locking is not required when cursor offload is in progress since the updates are consolidated and processed by DMU once at the end of the frame in a periodic manner. The shared buffer the firmware queries from is allocated along with the rest of the scratch state region in an area that's accessible by both firmware and driver. The size of the cursor offload (v1) state will not change, but it does have a unique union per ASIC version with room for expansion if needed. When firmware features notifying DMU of DRR updates are not enabled we now send an explicit vtotal min/max update via driver to DMU firmware whenever the vtotal max changes. This is to allow the cursor programming to determine the appropriate latch update point offset from vupdate. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions