| 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). 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
|
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel