From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 1131C9864DF for ; Thu, 9 Sep 2021 01:33:07 +0000 (UTC) MIME-Version: 1.0 References: <20210826021313.378-3-gurchetansingh@chromium.org> <20210830194155.882-1-gurchetansingh@chromium.org> In-Reply-To: From: Gurchetan Singh Date: Wed, 8 Sep 2021 18:32:51 -0700 Message-ID: Subject: Re: [virtio-comment] [RFC PATCH v2 2/2] virtio-gpu: add context init support Content-Type: multipart/alternative; boundary="000000000000d89f1505cb85fa86" To: Chia-I Wu Cc: virtio-comment@lists.oasis-open.org, Gerd Hoffmann List-ID: --000000000000d89f1505cb85fa86 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 2, 2021 at 9:59 AM Chia-I Wu wrote: > On Mon, Aug 30, 2021 at 12:42 PM Gurchetan Singh > wrote: > > +\item[\field{info}] Information associated with the command. If > > + VIRTIO_GPU_F_CONTEXT_INIT is supported, then the driver MAY set > > + VIRTIO_GPU_FLAG_INFO_RING_IDX bit in the request \field{flags}. In > > + that case: > > + \begin{itemize*} > > + \item VIRTIO_GPU_FLAG_FENCE MUST also be set > VIRTIO_GPU_FLAG_FENCE is optional currently and has a cost. There > might be use cases where fencing is not needed even with rings. Why > is it required when VIRTIO_GPU_FLAG_INFO_RING_IDX is set? > The latest non-RFC spec changes don't require VIRTIO_GPU_FLAG_INFO_RING_IDX + VIRTIO_GPU_FLAG_FENCE to go in unison. Implementation-wise, command buffer submission always sets VIRTIO_GPU_FLAG_FENCE at the moment (prior behavior unchanged with multiple-rings). More guest-side changes (say VIRTGPU_EXECBUF_NO_WAIT) would be required if one wants to submit a command without waiting for a response (or use the ASG technique). > > > + \item the lower 5 bits of \field{info} indicates the value of a > > + context-specific ring index. The minimum value is 0 and maximum > > + value is 31. > For Venus at least, we plan to assign each VkQueue of each logical > VkDevice a ring index. While 32 for a logical VkDevice seems enough > (TM), there are apps that require more than one logical device. > > Should we reserve 8 bits and allow up to 63? This way the last two > bits can be flexible if we run out of bit space in the future. > Done. > > > + \item \field{fence_id} acts as a sequence number on the > synchronization > > + timeline defined by \field{ctx_idx} and the ring index. > > + \item when the command associated with \field{fence_id} is complete, > the > > + device MUST send a response for all outstanding commands with a > sequence > > + number less than or equal to \field{fence_id} on the same > > + synchronization timeline. > > + \end{itemize*} > > \end{description} > > > > On success the device will return VIRTIO_GPU_RESP_OK_NODATA in > > @@ -516,6 +533,12 @@ \subsubsection{Device Operation: > controlq}\label{sec:Device Types / GPU Device / > > the first edition of Virgl (Gallium OpenGL) protocol. > > \item \href{ > https://gitlab.freedesktop.org/virgl/virglrenderer/-/blob/master/src/virgl_hw.h#L550}{VIRTIO_GPU_CAPSET_VIRGL2} > -- > > the second edition of Virgl (Gallium OpenGL) protocol after the > capset fix. > > + \item \href{ > https://android.googlesource.com/device/generic/vulkan-cereal/+/refs/heads/master/protocols/}{VIRTIO_GPU_CAPSET_GFXSTREAM > } > -- > > + gfxtream's (mostly) autogenerated GLES and Vulkan streaming > protocols. > > + \item \href{ > https://gitlab.freedesktop.org/olv/venus-protocol}{VIRTIO_GPU_CAPSET_VENUS} > -- > > + Mesa's (mostly) autogenerated Vulkan protocol. > > + \item \href{ > https://chromium.googlesource.com/chromiumos/platform/crosvm/+/refs/heads/main/rutabaga_gfx/src/cross_domain/cross_domain_protocol.rs}{VIRTIO_GPU_CAPSET_CROSS_DOMAIN > } > -- > > + protocol for display virtualization via Wayland proxying. > > \end{itemize*} > > > > \begin{lstlisting} > > @@ -527,6 +550,9 @@ \subsubsection{Device Operation: > controlq}\label{sec:Device Types / GPU Device / > > > > #define VIRTIO_GPU_CAPSET_VIRGL 1 > > #define VIRTIO_GPU_CAPSET_VIRGL2 2 > > +#define VIRTIO_GPU_CAPSET_GFXSTREAM 3 > > +#define VIRTIO_GPU_CAPSET_VENUS 4 > > +#define VIRTIO_GPU_CAPSET_CROSS_DOMAIN 5 > > struct virtio_gpu_resp_capset_info { > > struct virtio_gpu_ctrl_hdr hdr; > > le32 capset_id; > > @@ -684,21 +710,46 @@ \subsubsection{Device Operation: controlq > (3d)}\label{sec:Device Types / GPU Dev > > > > \begin{description} > > > > -\item[VIRTIO_GPU_CMD_CTX_CREATE] > > +\item[VIRTIO_GPU_CMD_CTX_CREATE] creates a context for submitting an > opaque > > + command stream. Request data is \field{struct virtio_gpu_ctx_create}. > > + Response type is VIRTIO_GPU_RESP_OK_NODATA. > > + > > +\begin{lstlisting} > > +#define VIRTIO_GPU_CONTEXT_INIT_CAPSET_ID_MASK 0x0000003f; > > +struct virtio_gpu_ctx_create { > > + struct virtio_gpu_ctrl_hdr hdr; > > + le32 nlen; > > + le32 context_init; > > + char debug_name[64]; > > +}; > > +\end{lstlisting} > > + > > +The implementation MUST create a context for the given \field{ctx_id} in > > +the \field{hdr}. For debugging purposes, a \field{debug_name} and it's > > +length \field{nlen} is provided by the driver. If > > +VIRTIO_GPU_F_CONTEXT_INIT is supported, then lower 6 bits of > > +\field{context_init} MAY contain the \field{capset_id} associated with > > +context. In that case, then the device MUST create a context that can > > +handle the specified command stream. > > + > > +If the lower 6-bits of the \field{context_init} are zero, then the type > of > > +the context is determined by the device. > > + > > \item[VIRTIO_GPU_CMD_CTX_DESTROY] > > \item[VIRTIO_GPU_CMD_CTX_ATTACH_RESOURCE] > > \item[VIRTIO_GPU_CMD_CTX_DETACH_RESOURCE] > > - Manage OpenGL contexts. > > + Manage virtio-gpu 3d contexts. > > > > \item[VIRTIO_GPU_CMD_RESOURCE_CREATE_3D] > > - Create OpenGL resources. > > + Create virtio-gpu 3d resources. > > > > \item[VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D] > > \item[VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D] > > - Transfer data from and to OpenGL resources. > > + Transfer data from and to virtio-gpu 3d resources. > > > > \item[VIRTIO_GPU_CMD_SUBMIT_3D] > > - Submit rendering commands (mesa gallium command stream). > > + Submit an opaque command stream. The type of the command stream is > > + determined when creating a context. > > > > \item[VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB] maps a host-only > > blob resource into an offset in the host visible memory region. > Request > > -- > > 2.31.0 > > > > > > This publicly archived list offers a means to provide input to the > > OASIS Virtual I/O Device (VIRTIO) TC. > > > > In order to verify user consent to the Feedback License terms and > > to minimize spam in the list archive, subscription is required > > before posting. > > > > Subscribe: virtio-comment-subscribe@lists.oasis-open.org > > Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org > > List help: virtio-comment-help@lists.oasis-open.org > > List archive: https://lists.oasis-open.org/archives/virtio-comment/ > > Feedback License: > https://www.oasis-open.org/who/ipr/feedback_license.pdf > > List Guidelines: > https://www.oasis-open.org/policies-guidelines/mailing-lists > > Committee: https://www.oasis-open.org/committees/virtio/ > > Join OASIS: https://www.oasis-open.org/join/ > > > --000000000000d89f1505cb85fa86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 2, 2021 at 9:59 AM Chia-I= Wu <olvaffe@gmai= l.com> wrote:
On Mon, Aug 30, 2021 at 12:42 PM Gurchetan Singh
<gurche= tansingh@chromium.org> wrote:
> +\item[\field{info}] Information associated with the command.=C2=A0 If=
> +=C2=A0 VIRTIO_GPU_F_CONTEXT_INIT is supported, then the driver MAY se= t
> +=C2=A0 VIRTIO_GPU_FLAG_INFO_RING_IDX bit in the request \field{flags}= .=C2=A0 In
> +=C2=A0 that case:
> +=C2=A0 \begin{itemize*}
> +=C2=A0 \item VIRTIO_GPU_FLAG_FENCE MUST also be set
VIRTIO_GPU_FLAG_FENCE is optional currently and has a cost.=C2=A0 There
might be use cases where fencing is not needed even with rings.=C2=A0 Why is it required when VIRTIO_GPU_FLAG_INFO_RING_IDX is set?
<= div>
The latest non-RFC spec changes don't require VIRTIO= _GPU_FLAG_INFO_RING_IDX=C2=A0+=C2=A0VIRTIO_GPU_FLAG_FENCE to go in unison.= =C2=A0 Implementation-wise, command buffer submission always sets VIRTIO_GP= U_FLAG_FENCE at the moment (prior behavior unchanged with multiple-rings).= =C2=A0 More guest-side changes (say VIRTGPU_EXECBUF_NO_WAIT) would be requi= red if one wants to submit a command without waiting for a response (or use= the ASG technique).
=C2=A0

> +=C2=A0 \item the lower 5 bits of \field{info} indicates the value of = a
> +=C2=A0 =C2=A0context-specific ring index.=C2=A0 The minimum value is = 0 and maximum
> +=C2=A0 =C2=A0value is 31.
For Venus at least, we plan to assign each VkQueue of each logical
VkDevice a ring index.=C2=A0 While 32 for a logical VkDevice seems enough (TM), there are apps that require more than one logical device.

Should we reserve 8 bits and allow up to 63?=C2=A0 This way the last two bits can be flexible if we run out of bit space in the future.

Done.=C2=A0


=C2=A0

> +=C2=A0 \item \field{fence_id} acts as a sequence number on the synchr= onization
> +=C2=A0 =C2=A0timeline defined by \field{ctx_idx} and the ring index.<= br> > +=C2=A0 \item when the command associated with \field{fence_id} is com= plete, the
> +=C2=A0 device MUST send a response for all outstanding commands with = a sequence
> +=C2=A0 number less than or equal to \field{fence_id} on the same
> +=C2=A0 synchronization timeline.
> +=C2=A0 \end{itemize*}
>=C2=A0 \end{description}
>
>=C2=A0 On success the device will return VIRTIO_GPU_RESP_OK_NODATA in > @@ -516,6 +533,12 @@ \subsubsection{Device Operation: controlq}\label{= sec:Device Types / GPU Device /
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the first edition of Virgl (Gallium O= penGL) protocol.
>=C2=A0 =C2=A0 \item \href{https://gitlab.freedesktop.org/= virgl/virglrenderer/-/blob/master/src/virgl_hw.h#L550}{VIRTIO_GPU_CAPSET_VI= RGL2} --
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the second edition of Virgl (Gallium = OpenGL) protocol after the capset fix.
> +=C2=A0 \item \href{https://android.googlesou= rce.com/device/generic/vulkan-cereal/+/refs/heads/master/protocols/}{VIRTIO= _GPU_CAPSET_GFXSTREAM} --
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0gfxtream's (mostly) autogenerated GLES= and Vulkan streaming protocols.
> +=C2=A0 \item \href{https://gitlab.freedesktop.org/olv/venus-protocol}{VIRTIO_GPU_CAPSET_VEN= US} --
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0Mesa's (mostly) autogenerated Vulkan p= rotocol.
> +=C2=A0 \item \href{https://chromium.googlesource.com/chromiumos/platform/cr= osvm/+/refs/heads/main/rutabaga_gfx/src/cross_domain/cross_domain_protocol.= rs}{VIRTIO_GPU_CAPSET_CROSS_DOMAIN} --
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0protocol for display virtualization via Wa= yland proxying.
>=C2=A0 =C2=A0 \end{itemize*}
>
>=C2=A0 \begin{lstlisting}
> @@ -527,6 +550,9 @@ \subsubsection{Device Operation: controlq}\label{s= ec:Device Types / GPU Device /
>
>=C2=A0 #define VIRTIO_GPU_CAPSET_VIRGL 1
>=C2=A0 #define VIRTIO_GPU_CAPSET_VIRGL2 2
> +#define VIRTIO_GPU_CAPSET_GFXSTREAM 3
> +#define VIRTIO_GPU_CAPSET_VENUS 4
> +#define VIRTIO_GPU_CAPSET_CROSS_DOMAIN 5
>=C2=A0 struct virtio_gpu_resp_capset_info {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct virtio_gpu_ctrl_hdr hdr;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 le32 capset_id;
> @@ -684,21 +710,46 @@ \subsubsection{Device Operation: controlq (3d)}\= label{sec:Device Types / GPU Dev
>
>=C2=A0 \begin{description}
>
> -\item[VIRTIO_GPU_CMD_CTX_CREATE]
> +\item[VIRTIO_GPU_CMD_CTX_CREATE] creates a context for submitting an = opaque
> +=C2=A0 command stream.=C2=A0 Request data is \field{struct virtio_gpu= _ctx_create}.
> +=C2=A0 Response type is VIRTIO_GPU_RESP_OK_NODATA.
> +
> +\begin{lstlisting}
> +#define VIRTIO_GPU_CONTEXT_INIT_CAPSET_ID_MASK 0x0000003f;
> +struct virtio_gpu_ctx_create {
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0struct virtio_gpu_ctrl_hdr hdr;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0le32 nlen;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0le32 context_init;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0char debug_name[64];
> +};
> +\end{lstlisting}
> +
> +The implementation MUST create a context for the given \field{ctx_id}= in
> +the \field{hdr}.=C2=A0 For debugging purposes, a \field{debug_name} a= nd it's
> +length \field{nlen} is provided by the driver.=C2=A0 If
> +VIRTIO_GPU_F_CONTEXT_INIT is supported, then lower 6 bits of
> +\field{context_init} MAY contain the \field{capset_id} associated wit= h
> +context.=C2=A0 In that case, then the device MUST create a context th= at can
> +handle the specified command stream.
> +
> +If the lower 6-bits of the \field{context_init} are zero, then the ty= pe of
> +the context is determined by the device.
> +
>=C2=A0 \item[VIRTIO_GPU_CMD_CTX_DESTROY]
>=C2=A0 \item[VIRTIO_GPU_CMD_CTX_ATTACH_RESOURCE]
>=C2=A0 \item[VIRTIO_GPU_CMD_CTX_DETACH_RESOURCE]
> -=C2=A0 Manage OpenGL contexts.
> +=C2=A0 Manage virtio-gpu 3d contexts.
>
>=C2=A0 \item[VIRTIO_GPU_CMD_RESOURCE_CREATE_3D]
> -=C2=A0 Create OpenGL resources.
> +=C2=A0 Create virtio-gpu 3d resources.
>
>=C2=A0 \item[VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D]
>=C2=A0 \item[VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D]
> -=C2=A0 Transfer data from and to OpenGL resources.
> +=C2=A0 Transfer data from and to virtio-gpu 3d resources.
>
>=C2=A0 \item[VIRTIO_GPU_CMD_SUBMIT_3D]
> -=C2=A0 Submit rendering commands (mesa gallium command stream).
> +=C2=A0 Submit an opaque command stream.=C2=A0 The type of the command= stream is
> +=C2=A0 determined when creating a context.
>
>=C2=A0 \item[VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB] maps a host-only
>=C2=A0 =C2=A0 blob resource into an offset in the host visible memory r= egion. Request
> --
> 2.31.0
>
>
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: virtio-comment-subscribe@lists.oasis-open.org > Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org=
> List help: virtio-comment-help@lists.oasis-open.org
> List archive: https://lists.oasis-open.org= /archives/virtio-comment/
> Feedback License: https://www.oasis-open= .org/who/ipr/feedback_license.pdf
> List Guidelines: https://www.oasis-= open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/v= irtio/
> Join OASIS: https://www.oasis-open.org/join/
>
--000000000000d89f1505cb85fa86--