Re: [PATCH 3/3] virtio-gpu api: VIRTIO_GPU_F_RESSOURCE_V2

[Gurchetan Singh <gurchetansingh@chromium.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3363 bytes --]

On Wed, Apr 10, 2019 at 4:42 AM Gerd Hoffmann <kraxel@redhat.com> wrote:

> Add new command VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 to create resources.
> It adds (a) support planar resources and (b) returns stride and size of
> the resource planes.  The later will be needed in case we support
> mapping host resources into the guest some day.


Thanks for looking into this!  Definitely need something like this for
sharing buffers between display, gpu and multimedia units.  Userspace
implementation?  Not sure if this is required for kernel api commits or not.


> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  include/uapi/linux/virtio_gpu.h | 31 +++++++++++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
>
> diff --git a/include/uapi/linux/virtio_gpu.h
> b/include/uapi/linux/virtio_gpu.h
> index 732bb16a39f8..00010315e500 100644
> --- a/include/uapi/linux/virtio_gpu.h
> +++ b/include/uapi/linux/virtio_gpu.h
> @@ -58,6 +58,11 @@
>   */
>  #define VIRTIO_GPU_F_MEMORY              2
>
> +/*
> + * VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 command
> + */
> +#define VIRTIO_GPU_F_RESSOURCE_V2        3
> +
>  enum virtio_gpu_ctrl_type {
>         VIRTIO_GPU_UNDEFINED = 0,
>
> @@ -76,6 +81,7 @@ enum virtio_gpu_ctrl_type {
>         VIRTIO_GPU_CMD_MEMORY_CREATE,
>         VIRTIO_GPU_CMD_MEMORY_UNREF,
>         VIRTIO_GPU_CMD_RESOURCE_ATTACH_MEMORY,
> +       VIRTIO_GPU_CMD_RESOURCE_CREATE_V2,
>
>         /* 3d commands */
>         VIRTIO_GPU_CMD_CTX_CREATE = 0x0200,
> @@ -97,6 +103,7 @@ enum virtio_gpu_ctrl_type {
>         VIRTIO_GPU_RESP_OK_CAPSET_INFO,
>         VIRTIO_GPU_RESP_OK_CAPSET,
>         VIRTIO_GPU_RESP_OK_EDID,
> +       VIRTIO_GPU_RESP_OK_RESOURCE_INFO,
>
>         /* error responses */
>         VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200,
> @@ -308,6 +315,30 @@ struct virtio_gpu_cmd_resource_attach_memory {
>         __le64 offset[4];
>  };
>
> +/* VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 */
> +struct virtio_gpu_cmd_resource_create_v2 {
> +       struct virtio_gpu_ctrl_hdr hdr;
> +       __le32 resource_id;
> +       __le32 format;
> +       __le32 width;
> +       __le32 height;
> +       /* 3d only */
> +       __le32 target;
> +       __le32 bind;
> +       __le32 depth;
> +       __le32 array_size;
> +       __le32 last_level;
> +       __le32 nr_samples;
> +       __le32 flags;
> +};


I assume this is always backed by some host side allocation, without any
guest side pages associated with it?

If so, do we want the option for the guest allocate?  We're basing this off
gbm, which will do the host side allocation for us.  But userspace
libraries could change (maybe something like the proposed Unix Device
Memory Allocator takes off).
The host, in theory, could return the the metadata required about an
allocation to virtio-gpu to use guest pages.  With guest allocation we can
be more like Vulkan in that regard (see vkGetImageMemoryRequirements,
followed by vkAllocateMemory), and use udmabuf to share.  But not all hosts
can support that, so maybe having an API for both methods would be useful.



> +/* VIRTIO_GPU_RESP_OK_RESOURCE_INFO */
> +struct virtio_gpu_resp_resource_info {
> +       struct virtio_gpu_ctrl_hdr hdr;
> +       __le32 stride[4];
> +       __le32 size[4];
> +};
>

offsets[4] needed too


> +
>  #define VIRTIO_GPU_CAPSET_VIRGL 1
>  #define VIRTIO_GPU_CAPSET_VIRGL2 2
>
> --
> 2.18.1
>
>

[-- Attachment #1.2: Type: text/html, Size: 4750 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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