OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [PATCH v1] virtio-gpu: Document new fence-passing feature




On Sun, Jan 28, 2024 at 11:12âAM Dmitry Osipenko <dmitry.osipenko@collabora.com> wrote:
Document new virtio-gpu protocol fence-passing feature that extends 3d
submit command with support of in-fences which are passed from guest to
host for waiting. This feature allows to offload waiting for in-fences
from guest to host, where it can be done more efficiently.

Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
Âdevice-types/gpu/description.tex | 22 +++++++++++++++++++++-
Â1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/device-types/gpu/description.tex b/device-types/gpu/description.tex
index 443524851a05..e5e23b5c9072 100644
--- a/device-types/gpu/description.tex
+++ b/device-types/gpu/description.tex
@@ -37,6 +37,8 @@ \subsection{Feature bits}\label{sec:Device Types / GPU Device / Feature bits}
 Âresources is supported.
Â\item[VIRTIO_GPU_F_CONTEXT_INIT (4)] multiple context types and
 Âsynchronization timelines supported. Requires VIRTIO_GPU_F_VIRGL.
+\item[VIRTIO_GPU_F_FENCE_PASSING (5)] passing fence IDs from guest to host
+ for waiting supported. Requires VIRTIO_GPU_F_VIRGL.
Â\end{description}

Â\subsection{Device configuration layout}\label{sec:Device Types / GPU Device / Device configuration layout}
@@ -746,7 +748,25 @@ \subsubsection{Device Operation: controlq (3d)}\label{sec:Device Types / GPU Dev

Â\item[VIRTIO_GPU_CMD_SUBMIT_3D]
 ÂSubmit an opaque command stream. The type of the command stream is
-Â determined when creating a context.
+ determined when creating a context. Request data is
+ \field{struct virtio_gpu_cmd_submit}. The \field{size} field describes
+ the size of \field{cmd_data} array in bytes. The \field{num_in_fences}
+Â field is active only if VIRTIO_GPU_F_FENCE_PASSING is enabled, otherwise
+ \field{num_in_fences} is treated as zero. The array of \field{in_fences}
+Â IDs is placed in between the \field{num_in_fences} field and the
+ \field{cmd_data} array. The \field{in_fences} array contains virtio-gpu
+Â \field{fence_id}'s corresponding to the out-fence IDs of a previous
+Â 3d submits.
+
+\begin{lstlisting}
+struct virtio_gpu_cmd_submit {
+Â Â Â Â struct virtio_gpu_ctrl_hdr hdr;
+Â Â Â Â le32 size;
+Â Â Â Â le32 num_in_fences;
+Â Â Â Â le64 in_fences[num_in_fences];
+Â Â Â Â u32 cmd_data[size/4];
+};
+\end{lstlisting}

Don't you need VIRTIO_GPU_FLAG_FENCE_SHAREABLE somewhere too?
Â

Â\item[VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB] maps a host-only
 Âblob resource into an offset in the host visible memory region. Request
--
2.43.0



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]