summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorRob Clark <robdclark@chromium.org>2025-06-29 13:12:56 -0700
committerRob Clark <robin.clark@oss.qualcomm.com>2025-07-04 17:48:35 -0700
commit111fdd2198e63b1e19ce015d95692d27bf6ce3fa (patch)
tree1967e2df0c1d864fb4a065573cf9d85839b35aa6 /tools/perf/scripts/python
parent8ac37c88f991257215400ad30ee9087dbc7c0a1b (diff)
drm/msm: drm_gpuvm conversion
Now that we've realigned deletion and allocation, switch over to using drm_gpuvm/drm_gpuva. This allows us to support multiple VMAs per BO per VM, to allow mapping different parts of a single BO at different virtual addresses, which is a key requirement for sparse/VM_BIND. This prepares us for using drm_gpuvm to translate a batch of MAP/ MAP_NULL/UNMAP operations from userspace into a sequence of map/remap/ unmap steps for updating the page tables. Since, unlike our prior vm/vma setup, with drm_gpuvm the vm_bo holds a reference to the GEM object. To prevent reference loops causing us to leak all GEM objects, we implicitly tear down the mapping when the GEM handle is close or when the obj is unpinned. Which means the submit needs to also hold a reference to the vm_bo, to prevent the VMA from being torn down while the submit is in-flight. Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Tested-by: Antonino Maniscalco <antomani103@gmail.com> Reviewed-by: Antonino Maniscalco <antomani103@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/661479/
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions