[Spice-devel] RFC: Integrating Virgil and Spice

[Hans de Goede]

Hi,

On 10/08/2013 03:18 PM, Gerd Hoffmann wrote:
>    Hi,
>
>> The basic idea is to use qemu's console layer (include/ui/console.h)
>> as an abstraction between the new virtio-vga device Dave has in mind
>> (which will include optional 3D rendering capability through VIRGIL),
>> and various display options, ie SDL, vnc and Spice.
>>
>> The console layer would need some extensions for this:

<snip>

>> 2) The ability for a video-card generating output to pass a dma-buf
>> context to the display (ui in qemu terms) to get the contents from,
>> rather then requiring the contents to be rendered to some memory
>> buffer. This way we can save the quite expensive read-back from gpu
>> memory of the rendered result and then copying that back to the
>> framebuffer of the gpu for local displays (ie gtk, SDL),
>
> Hmm?  Not sure what you are asking for...
>
> First, reading from gpu memory isn't expensive.  It's all virtual, no
> slow read cycles as with real hardware.  There is almost no difference
> between gpu memory and main memory for kvm guests.  It's not clear to me
> why you are copying stuff from/to gpu memory.

This is mostly Dave's area of expertise, but let me try to explain things
a bit better here. The dma-buf pass-through is for the Virgil case, so
we're passing through 3D rendering commands from the guest to a real,
physcial GPU inside the host, which then renders the final image to show
inside the ui to its own, potentially on card, memory, reading from which
is expensive.

When displaying locally (so SDL-2 or gtk ui), we want to avoid the read by
passing a kernel dma_buf handle from the virtual card (in this case
virtio-vga with Virgil) to the ui (in this case SDL-2), so it can then
directly ask the GPU to blit from that dma_buf to its own visible surface.

> Second, you can have your scanout framebuffer in main memory.  That
> isn't a problem at all.  It only needs to be contiguous in guest
> physical memory, scatter-gather for the framebuffer isn't going to fly.

This is not about the virtual gpu / virtual scanout buffer, this is
about a real GPU used to do the (final) rendering and about getting
that rendering shown to a local user (ie SDL or gtk ui).

So the rendered image is stored in memory owned by the real GPU, and
we need to get this "copied" to the window the user is viewing, without
using the CPU.

>> For proper multi-head support in the ui layer for local displays,
>> we will need to use SDL-2, either by porting the current SDL ui code
>> to SDL-2, or by introducing a new SDL-2 ui component.
>
> /me votes for new SDL-2 ui component, the historical grown SDL code can
> use a rewrite anyway ;)

I was already expecting you would prefer the new SDL-2 ui component
solution :)

Regards,

Hans