Re: [virtio-comment] [RFC PATCH v2 2/2] virtio-gpu: add context init support

[Gurchetan Singh <gurchetansingh@chromium.org>]

On Thu, Sep 2, 2021 at 9:59 AM Chia-I Wu <olvaffe@gmail.com> wrote:

On Mon, Aug 30, 2021 at 12:42 PM Gurchetan Singh
<gurchetansingh@chromium.org> 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/
>