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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
