search for: gpuva_region

...r tracking the VA allocations >>>>>>> (drm_mm based) and a different component/interface for tracking >>>>>>> the VA mappings (probably rb tree based). >>>>>> >>>>>> That's what the GPUVA manager is doing. There are gpuva_regions >>>>>> which correspond to VA allocations and gpuvas which represent the >>>>>> mappings. Both are tracked separately (currently both with a >>>>>> separate drm_mm, though). However, the GPUVA manager needs to >>>>>> take...

...hat you want is one component for tracking the VA allocations >>>>> (drm_mm based) and a different component/interface for tracking the >>>>> VA mappings (probably rb tree based). >>>> >>>> That's what the GPUVA manager is doing. There are gpuva_regions >>>> which correspond to VA allocations and gpuvas which represent the >>>> mappings. Both are tracked separately (currently both with a >>>> separate drm_mm, though). However, the GPUVA manager needs to take >>>> regions into account when dealin...

...t;>>> What you want is one component for tracking the VA allocations >>>> (drm_mm based) and a different component/interface for tracking the >>>> VA mappings (probably rb tree based). >>> >>> That's what the GPUVA manager is doing. There are gpuva_regions >>> which correspond to VA allocations and gpuvas which represent the >>> mappings. Both are tracked separately (currently both with a >>> separate drm_mm, though). However, the GPUVA manager needs to take >>> regions into account when dealing with mappings...

...t you want is one component for tracking the VA allocations > >>>> (drm_mm based) and a different component/interface for tracking the > >>>> VA mappings (probably rb tree based). > >>> > >>> That's what the GPUVA manager is doing. There are gpuva_regions > >>> which correspond to VA allocations and gpuvas which represent the > >>> mappings. Both are tracked separately (currently both with a > >>> separate drm_mm, though). However, the GPUVA manager needs to take > >>> regions into account when dealin...

...erwise, we could also add an option to > the GPUVA manager (or a specific region, which could also be a single > huge one) within which it never merges. > >> >> If this can be removed then the entire concept of regions in the GPUVA >> can be removed too (drop struct drm_gpuva_region). I say this because >> in Xe as I'm porting over to GPUVA the first thing I'm doing after >> drm_gpuva_manager_init is calling drm_gpuva_region_insert on the entire >> address space. To me this seems kinda useless but maybe I'm missing why >> you need this for N...