search for: extobjs

...gt;>>>> like XE or Nouveau, we'd at least need to make sure to not mess up the locking >>>>> hierarchy of GPU-VM lock and dma-resv lock of the corresponding BO. >>>>> >>>>> Considering all that, I thought it's probably better to track extobjs separate >>>>> from the drm_gpuva_gem, hence the maple tree choice. >>>> Hm. OK, in Xe we're having a list of the xe_vmas (drm_gpuvas) that point to >>>> external objects, or in the case of multiple mappings to the same gem >>>> object, only on...

Am 10.10.23 um 22:23 schrieb Dave Airlie: >> I think we're then optimizing for different scenarios. Our compute >> driver will use mostly external objects only, and if shared, I don't >> forsee them bound to many VMs. What saves us currently here is that in >> compute mode we only really traverse the extobj list after a preempt >> fence wait, or when a vm is

On Wed, 11 Oct 2023 at 17:07, Christian K?nig <christian.koenig at amd.com> wrote: > > Am 10.10.23 um 22:23 schrieb Dave Airlie: > >> I think we're then optimizing for different scenarios. Our compute > >> driver will use mostly external objects only, and if shared, I don't > >> forsee them bound to many VMs. What saves us currently here is that in

Am 12.10.23 um 12:33 schrieb Dave Airlie: > On Wed, 11 Oct 2023 at 17:07, Christian K?nig <christian.koenig at amd.com> wrote: >> Am 10.10.23 um 22:23 schrieb Dave Airlie: >>>> I think we're then optimizing for different scenarios. Our compute >>>> driver will use mostly external objects only, and if shared, I don't >>>> forsee them bound

So far the DRM GPUVA manager offers common infrastructure to track GPU VA allocations and mappings, generically connect GPU VA mappings to their backing buffers and perform more complex mapping operations on the GPU VA space. However, there are more design patterns commonly used by drivers, which can potentially be generalized in order to make the DRM GPUVA manager represent a basic GPU-VM