search for: gem_object

...the bo is registered and someone can call the handle2fd ioctl on it. Aside: ttm_buffer_object.ttm_resv could probably be ditched in favour of always passing a non-NULL resv to ttm_bo_init(). At least for gem drivers that would avoid having two of these, on in ttm_buffer_object and the other in drm_gem_object, one just there for confusion. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_bo.c | 2 ++ drivers/gpu/drm/nouveau/nouveau_drm.c | 1 - drivers/gpu/drm/nouve...

...the bo is registered and someone can call the handle2fd ioctl on it. Aside: ttm_buffer_object.ttm_resv could probably be ditched in favour of always passing a non-NULL resv to ttm_bo_init(). At least for gem drivers that would avoid having two of these, on in ttm_buffer_object and the other in drm_gem_object, one just there for confusion. Reviewed-by: Emil Velikov <emil.velikov at collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_bo.c | 2 ++ driv...

...the bo is registered and someone can call the handle2fd ioctl on it. Aside: ttm_buffer_object.ttm_resv could probably be ditched in favour of always passing a non-NULL resv to ttm_bo_init(). At least for gem drivers that would avoid having two of these, on in ttm_buffer_object and the other in drm_gem_object, one just there for confusion. Acked-by: Gerd Hoffmann <kraxel at redhat.com> Cc: Gerd Hoffmann <kraxel at redhat.com> Reviewed-by: Emil Velikov <emil.velikov at collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Ben Skeggs <bskeggs at redhat.co...

Am 10.11.23 um 10:39 schrieb Thomas Hellstr?m: > > [SNIP] > I was thinking more of the general design of a base-class that needs > to be refcounted. Say a driver vm that inherits from gpu-vm, > gem_object and yet another base-class that supplies its own refcount. > What's the best-practice way to do refcounting? All base-classes > supplying a refcount of its own, or the subclass supplying a refcount > and the base-classes supply destroy helpers. From my experience the most common d...

...>>> the driver's subclass provide get() and put() ops, and export a >>>> destructor for the base-class, rather than to have the base-class >>>> provide the refcount and a destructor? ops. >> >> GPUVM simply follows the same pattern we have with drm_gem_objects. >> And I think it makes >> sense. Why would we want to embed two struct drm_gpuvm in a single >> driver structure? > > Because you need one drm_gpuvm structure for each application using > the driver? Or am I missing something? > > As far as I can see a driver...

On 11/10/23 11:42, Christian K?nig wrote: > Am 10.11.23 um 10:39 schrieb Thomas Hellstr?m: >> >> [SNIP] > >> I was thinking more of the general design of a base-class that needs >> to be refcounted. Say a driver vm that inherits from gpu-vm, >> gem_object and yet another base-class that supplies its own refcount. >> What's the best-practice way to do refcounting? All base-classes >> supplying a refcount of its own, or the subclass supplying a refcount >> and the base-classes supply destroy helpers. > > From my experien...

...uld be to have the >>> driver's subclass provide get() and put() ops, and export a >>> destructor for the base-class, rather than to have the base-class >>> provide the refcount and a destructor? ops. > > GPUVM simply follows the same pattern we have with drm_gem_objects. > And I think it makes > sense. Why would we want to embed two struct drm_gpuvm in a single > driver structure? Because you need one drm_gpuvm structure for each application using the driver? Or am I missing something? As far as I can see a driver would want to embed that into your...