[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] [RFC PATCH v2 2/2] virtio-gpu: add context init support
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? > + \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. > + \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/ >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]