[Spice-devel] Windows 10 guest: 2D/3D Accel

Tue May 9 15:22:46 UTC 2017

Hi, Christophe,

Thanks a lot again for the detailed explanation.

I understand perfectly the difference between client, host and guest. In my
enviornment client is ferdora 25, host is Centos 7 and guest is Windows 10.

Regarding the 7th point:

*7. The “client” will talk to that protocol and display that on your
screen. The client itself may use 3D acceleration to display things on your
screen, but it’s not the “same” 3D acceleration as used in the guest. For
example, if it gets a video stream from the server in 6, now it’s using the
video decoding capabilities of the 3D card, even if your application in the
guest is rendering 3D objects.*

This means that the client (physical endpoint) will use the GPU just for
jpeg and mpeg decoding. It has no sense to buy an expensive card for the
endpoint, isn't it?

I may assume, that my physical endpoint (fedora based) that launches
virt-viewer or virt-manager, will use automatically the local gpu for jpeg,
mpeg rendering, in't it? or may I make further configuration?

Thanks a lot!

2017-05-09 16:56 GMT+02:00 Christophe de Dinechin <cdupontd at redhat.com>:

>
> On 9 May 2017, at 16:51, Christophe de Dinechin <cdupontd at redhat.com>
> wrote:
>
> Hi Oscar,
>
>
> For 3D acceleration in virtual machines, you need a multiplicity of
> components to cooperate:
>
> 1. The physical GPU needs to be supported by the host.
>
> 2. It needs to expose an API that the virtual machine software can access,
> e.g. OpenGL on Linux
>
> 3. The virtualisation software, e.g. KVM/QEMU, talks to the host GPU e.g.
> for graphic operations. That happens irrespective of how the guest sees the
> virtual hardware, i.e. irrespective of which of the methods Frediano
> referred to is used.
>
> 4. The virtual hardware exposed to the guest by the virtualisation
> software correspond to any of the solutions Frediano listed. This is true
> of any hardware, not just graphic cards (i.e. the same is true for
> networking cards). Again:
>
> a) A complete emulation of a real physical card, generally chosen to be a
> widely supported hardware standard (e.g. VGA)
>
> b) A simplified card that makes it easier to emulate, typically by
> accepting “higher level” commands. This is generally called
> “paravirtualization”
>
> c) A pass-through to a real hardware card, which is exposed to the guest
> by “poking a hole” in the virtualization so that the guest can see the real
> hardware. In general, that means the guest has complete control of that
> hardware, so you can’t share it with the host or with other guests.
>
> d) A smarter pass-through that only exposes part of the hardware. We talk
> about exposing “functions” of the host physical card.
>
> 5. Guest software, generally in the form of device drivers, that knows how
> to talk to the appropriate device listed in 4. In other words, you need a
> different driver to talk to an emulated VGA card (where you’d only use the
> regular VGA driver that comes with your OS) or to a para-virtualized card
> (where you’d use a special driver that knows about para-virtualization).
>
>
> I forgot to point out the key thing. What we are missing for 3D in Windows
> currently is this piece.
>
>
> In addition, for displays, you need to see what is happening in your
> guest. Except in cases 4c and possibly 4d, you don’t connect a screen
> directly to the graphic card of the guest, since there is no graphic card,
> only software. So instead:
>
> 6. You have special software in the virtualisation stack, a “server”, that
> takes whatever frame buffer the physical emulator in 4a or the
> paravirtualized driver in 4b has, and exposes it, typically in the form of
> some remote-viewing protocol like Spice or VNC.
>
> 7. The “client” will talk to that protocol and display that on your
> screen. The client itself may use 3D acceleration to display things on your
> screen, but it’s not the “same” 3D acceleration as used in the guest. For
> example, if it gets a video stream from the server in 6, now it’s using the
> video decoding capabilities of the 3D card, even if your application in the
> guest is rendering 3D objects.
>
> In conclusion, people often understand “client” as something like “the
> spice client”, i.e. the program in 7 used to connect to the server that
> exposes the virtual screen of the virtual machine. For the virtual machine
> itself, we generally prefer to use the term “guest”.
>
> I hope this makes sense.
>
>
> Cheers,
> Christophe
>
> On 9 May 2017, at 16:29, Oscar Segarra <oscar.segarra at gmail.com> wrote:
>
> Sorry Fredigano...
>
> I have read again your detailed response... and I cannot see the option
> where the client GPU is used... Is it expected the client GPU used with
> "option 2"
>
> Can you tell us when client GPU is used?
>
> Thanks a lot.
>
> 2017-05-09 13:31 GMT+02:00 Oscar Segarra <oscar.segarra at gmail.com>:
>
>> Ok, thanks for the detailed explanation... I'd suggest to publish it in
>> your webpage in order to help other users.
>>
>> Óscar.
>>
>> 2017-05-09 13:24 GMT+02:00 Frediano Ziglio <fziglio at redhat.com>:
>>
>>> There's a bit of confusion.
>>>
>>> The VM sees which cards the hypervisor (Qemu in this case) is configured
>>> to provide. As
>>> any card GPUs can be
>>> 1) physical, fully virtual
>>> 2) paravirtual
>>> 3) pass-through, specifically:
>>> 3.1) full pass-through
>>> 3.2) function pass-through
>>>
>>> 1) like VGA, a physical card is fully emulated, quite slow, there are
>>> some cards which are better than others as requires less guest <->
>>> hypervisor
>>> switches;
>>> 2) there are no physical card, the card is created just for virtual
>>> environment.
>>> This reduce the switches guest <-> hypervisor and optimized a lot of
>>> functions.
>>> Virgl cards, like QXL or VirtIO cards are like that. Are much more
>>> efficient
>>> and allows lot of features provided by virtual environment (like suspend
>>> or migration). The "best" for Qemu and 3d is surely Virgl but as said
>>> there's
>>> no Windows drivers at the moment;
>>> 3) you pass a full physical card or part of it. This CAN'T be used by
>>> the host
>>> and reduce control not allowing (usually) suspend and migration;
>>> 3.1) basically an entire physical card is passed to the guest. If you
>>> have an additional
>>> GPU (graphical card) you can do it;
>>> 3.2) some cards allow to provide part of its functions to be assigned
>>> like
>>> if were a physical card. For GPU currently Qemu/KVM does not provide
>>> much. Work is going to support Intel solutions and Nvidia ones.
>>> Nvidia ones are usually quite expensive (cards do not fit in either
>>> laptops
>>> or even desktops) while Intel offers some really cheap solutions using a
>>> mix of hardware/software solution.
>>>
>>> Frediano
>>>
>>>
>>> Hi Christophe,
>>>
>>> Thanks a lot for your clarifications... can you help me with the other
>>> questions?
>>>
>>> *Is there any way to check if is it using client GPU or host CPU?*
>>>
>>> *Is there any Grpahics card to be plugged in the host in order to use
>>> host GPU?*
>>>
>>> thanks a lot.
>>>
>>>
>>> 2017-05-09 12:03 GMT+02:00 Christophe Fergeau <cfergeau at redhat.com>:
>>>
>>>> Hey,
>>>>
>>>> On Tue, May 09, 2017 at 10:42:31AM +0200, Oscar Segarra wrote:
>>>> > Hi,
>>>> >
>>>> > What kind of drivers are required in windows? (I supose you mean
>>>> Windows
>>>> > guest).
>>>>
>>>> A video driver able to use virtio-gpu + virgl would be needed, but does
>>>> not exist at the moment. This is one of the Google Summer of Code
>>>> projects for this year though.
>>>>
>>>> Christophe
>>>>
>>>
>>>
>>>
>>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20170509/2ec5353c/attachment-0001.html>