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 <cdupo...@redhat.com>: > > On 9 May 2017, at 17:22, Oscar Segarra <oscar.sega...@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 <cdupo...@redhat.com>: > >> >> On 9 May 2017, at 16:51, Christophe de Dinechin <cdupo...@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.sega...@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.sega...@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 <fzig...@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 <cferg...@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@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/spice-devel >> >> >> _______________________________________________ >> Spice-devel mailing list >> Spice-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/spice-devel >> >> >> > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/spice-devel > > >
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
