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

Tue May 9 16:24:35 UTC 2017

Hi Christophe,

I think everything is pretty clear with the latest explanation.

Thanks a lot for your efford!

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

>
> On 9 May 2017, at 17:22, Oscar Segarra <oscar.segarra at gmail.com> wrote:
>
> 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.
>
>
> OK. Apologies if I sounded patronizing, I just wanted to make sure there
> was no confusion ;-)
>
>
> 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?
>
>
> If the reason is to accelerate 3D rendering, not with the current state of
> the technology. That being said, the possibility to send 3D data over the
> wire exists, and it may happen some day. But for now, there is indeed
> little benefit.
>
>
> 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?
>
>
> For JPEG, I think that you mostly get CPU-side acceleration
> (libjpeg-turbo). I think this uses SIMD instructions but no GPU that I know
> of. So I don’t think we use the GPU for JPEG at this point in time.
>
> For video, I’ll defer to others on this list. Spice uses gstreamer, which
> under specific situations can do hardware-assisted decoding (e.g. vaapi).
> But frankly, I’m still too new to the project to know precisely in which
> scenarios you get hardware assistance, and where this assistance comes from
> (i.e. it may be in some Intel chipset and not in the GPU ;-) I believe that
> the general answer is “it depends”.
>
>
> Cheers,
> Christophe
>
>
> 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
>>
>>
>>
> _______________________________________________
> 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/fa29b0ef/attachment-0001.html>