[PATCH v8 0/6] dcc: Create a stream for non-gl/remote clients that want to use dmabuf (v8)
Michael Scherle
michael.scherle at rz.uni-freiburg.de
Fri Sep 6 09:43:58 UTC 2024
Hi,
thank you very much for your reply. Of course I understand that
non-compiling/crashing code should not be merged into main.
Unfortunately I have not been able to reproduce this so far. Here's a
list of the systems I have tested on:
- Ubuntu server 20.04 LTS
AMD EPYC 7742
Intel Flex 140 with SR-IOV passthrough and without passthrough
- CentOS Stream 9
AMD EPYC 7742
Intel Flex 170 (SR-IOV)
- Ubuntu 22.04
8th Gen Intel with GVT-g and without passthrough
- Fedora 39
12th Gen Intel (SR-IOV)
Do you have an example system on which it does not compile/crash or what
the error messages are? Then I could possibly reproduce it and
contribute to a fix.
Greetings,
Michael
On 05.09.24 08:13, Frediano Ziglio wrote:
> Hi,
> I surely should get back to this.
>
> At the moment the series does not even compile on most of the supported systems.
> I understand that the feature works for some but merging in master not
> compiling code does not seem really nice to me.
> I think before merging code should compile and run, maybe with
> disabled features due to detected limitations but surely not crash if
> any unwritten and untested dependencies are not met.
>
> Regards,
> Frediano
>
> Il giorno ven 30 ago 2024 alle ore 12:53 Michael Scherle
> <michael.scherle at rz.uni-freiburg.de> ha scritto:
>>
>>
>>
>> On 10.06.24 20:34, Vivek Kasireddy wrote:
>>> For clients that cannot accept a dmabuf fd directly (such as those
>>> running on a remote system), this patch series provides a way for
>>> the Spice server to stream the gl/dmabuf data/buffer instead. This
>>> is mostly done by enabling the creation of Gst memory using a dmabuf
>>> fd as the source. This ability is useful given that dmabuf is the
>>> standard mechanism for sharing buffers between various drivers and
>>> userspace in many Graphics and Media usecases. Currently, this is
>>> tested with Qemu and remote-viewer using the x264enc/avdec_h264
>>> and msdkh264enc/dec plugins to stream the Guest/VM desktop but it
>>> can be easily extended to other plugins and applications.
>>>
>>> Here is roughly how things work:
>>> - The application (e.g, Qemu) chooses its preferred codec (a Gstreamer
>>> one) and calls gl_scanout (to update the fd) followed by gl_draw.
>>> - In response, the Spice server checks to see if the client is capable
>>> of accepting a dmabuf fd directly or not. If yes, the fd is forwarded
>>> directly to the client; otherwise, a new stream is created.
>>> - The Spice server then sends the dmabuf fd to the Gstreamer encoder
>>> which uses it as an input for creating an encoded buffer which is then
>>> sent to the client.
>>> - Once the encoding process is done, an async completion cookie is sent
>>> to the application.
>>>
>>> Here is a link to the previous version that used a drawable to share
>>> the dmabuf fd with the Gstreamer encoder:
>>> https://lists.freedesktop.org/archives/spice-devel/2023-January/052948.html
>>>
>>> This version is tested together with following (required) patches in qemu:
>>> https://gitlab.freedesktop.org/Vivek/qemu/-/commits/spice_gl_on_v4
>>>
>>> Changelog:
>>>
>>> v8:
>>> - Added a new gstreamer-encoder patch to this series to convert drm format
>>> shared by the VMM to the appropriate Gstreamer format.
>>>
>>> v7:
>>> - Revert back to the previous design where we do not share fd with the stream
>>> and scanout is the sole owner of the fd. This is because sharing fd ownership
>>> opens up a lot of corner cases.
>>>
>>> v6: (Frediano)
>>> - Properly share ownership of the dmabuf fd between stream and scanout
>>> - Ensure that a newly created stream is associated with all connected clients
>>>
>>> v5:
>>> - Addressed review comments from Frediano mainly regarding adding autoconf
>>> support for gstreamer-allocators dependency and not needing to access
>>> scanout as part of gl draw operation
>>>
>>> v4:
>>> - Test with Virgl enabled
>>> - Associate dmabuf's y0_top with stream's top_down variable
>>>
>>> v3:
>>> - Updated the second patch to have a new primary surface created
>>> whenever a new stream gets created. This will avoid having to
>>> trigger primary surface creation from Qemu. And, this change
>>> also fixes the following error seen with v2:
>>> ../server/display-channel.cpp:2074:display_channel_create_surface:
>>> condition `!display->priv->surfaces[surface_id]' failed
>>> - Rebase all patches on master
>>>
>>> v2:
>>> - Update all patches to address review comments from Frediano
>>> - Tested this series with msdkh264enc/dec plugins that will be added
>>> in another patch series
>>>
>>> Cc: Frediano Ziglio <freddy77 at gmail.com>
>>> Cc: Gerd Hoffmann <kraxel at redhat.com>
>>> Cc: Marc-André Lureau <marcandre.lureau at redhat.com>
>>> Cc: Dongwon Kim <dongwon.kim at intel.com>
>>>
>>> Vivek Kasireddy (6):
>>> dcc: Check to see if the client supports multiple codecs (v2)
>>> dcc: Create a stream associated with gl_draw for non-gl clients (v6)
>>> dcc-send: Encode and send gl_draw stream data to the remote client
>>> (v4)
>>> gstreamer-encoder: Add an encoder function that takes dmabuf fd as
>>> input (v3)
>>> gstreamer-encoder: Map the drm format to appropriate Gstreamer format
>>> video-stream: Don't stop a stream associated with gl_draw (v2)
>>>
>>> configure.ac | 2 +-
>>> meson.build | 2 +-
>>> server/dcc-send.cpp | 159 ++++++++++++++++----
>>> server/dcc.cpp | 31 ++--
>>> server/dcc.h | 6 +
>>> server/display-channel-private.h | 1 +
>>> server/display-channel.cpp | 1 +
>>> server/gstreamer-encoder.c | 246 ++++++++++++++++++++++++++-----
>>> server/video-encoder.h | 14 ++
>>> server/video-stream.cpp | 205 ++++++++++++++++++++++----
>>> server/video-stream.h | 4 +
>>> 11 files changed, 563 insertions(+), 108 deletions(-)
>>>
>>
>> I tested this patchset with several configurations:
>>
>> - With a passthrough intel gvt-g virtual gpu it works.
>>
>> - With virtio-vga it works.
>>
>> - With some extra patches to qemu and an virtualization driver it even
>> works with an virtual GPU from an SR-IOV-partitioned Intel Flex
>> 140 GPU. Note this extra patches are related to the gpu and not this
>> patchset.
>>
>> This patch is a significant improvement for handling graphically
>> demanding tasks or rapidly changing image content and is crucial for
>> SPICE to be a component of a competitive virtual desktop infrastructure.
>>
>> Tested-by: Michael Scherle <michael.scherle at rz.uni-freiburg.de>
>>
>> Greetings,
>> Michael
>>
More information about the Spice-devel
mailing list