Re: [RFC PATCH 0/8] *** Refactor struct virtgpu_object ***

[Gerd Hoffmann <kraxel@redhat.com>]

On Wed, Feb 26, 2020 at 04:25:53PM -0800, Gurchetan Singh wrote:
> The main motivation behind this is to have eventually have something like this:
> 
> struct virtio_gpu_shmem {
>     struct drm_gem_shmem_object base;
>     uint32_t hw_res_handle;
>     struct sg_table *pages;
>     (...)
> };
> 
> struct virtio_gpu_vram {
>     struct drm_gem_object base;  // or *drm_gem_vram_object
>     uint32_t hw_res_handle;
>     {offset, range};
>     (...)
> };

Given that we probably will not use drm_gem_vram_object and
drm_gem_shmem_object->base is drm_gem_object I think we can
go this route:

struct virtgpu_object {
	struct drm_gem_shmem_object base;
	enum object_type;
	uint32_t hw_res_handle;
	[ ... ]
};

struct virtgpu_object_shmem {
	struct virtgpu_object base;
	struct sg_table *pages;
	[ ... ]
};

struct virtgpu_object_hostmem {
	struct virtgpu_object base;
	{offset, range};
	(...)
};

Then have helpers to get virtgpu_object_hostmem / virtgpu_object_shmem
from virtgpu_object via container_of which also sanity-check
object_type (maybe we can check drm_gem_object->ops for that instead of
adding a new field).

> Sending this out to solicit feedback on this approach.  Whichever approach
> we decide, landing incremental changes to internal structures is reduces
> rebasing costs and avoids mega-changes.

That certainly makes sense.

cheers,
  Gerd

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel