On 03/25/2016 01:21 PM, poma wrote: > On 25.03.2016 10:02, Christophe Fergeau wrote: >> On Thu, Mar 24, 2016 at 01:26:17PM -0400, Cole Robinson wrote: >>> On 03/24/2016 01:08 PM, Christophe Fergeau wrote: >>>> Ah, I'll have to improve the text I guess. By "It's currently limited", >>>> I meant "Guest support is currently limited". (I tested this) >>>> >>> >>> Ah I see. So F23 guest has all the bits it needs, gotchya >> >> Mostly, the version which went into git says that mesa bits from >> copr:kraxel are needed on f23 guest. >> >>>>> >>>>> Slightly related question: what is the timeline for working gl passthrough >>>>> with local host + VM + spice listen=127.0.0.1 ? Is it under heavy development >>>>> or just waiting for just waiting for some new releases? If the latter, which >>>>> packages will be required? >>>> >>>> What do you expect out of it exactly ? To be able to do remote-viewer >>>> spice://localhost:5900 and have virgl acceleration work? Or something >>>> different? >>>> >>> >>> Basically the remote-viewer case you describe, since that's the default >>> virt-manager (and libvirt) config for spice setups. Gerd seemed to indicate >>> that it will work in the near term, in his response to your qemu patch. Isn't >>> that what the dmabuf stuff is all about? Or are we always going to have to use >>> the OpenGraphics/add_client method to get GL? >> >> As I understand it, the dmabuff stuff is just a file descriptor being >> passed around between virgl/QEMU and the SPICE client through a Unix >> socket so that the 3D framebuffer can be displayed in a different >> process. >> The discussion about gl+tcp was probably not a short-term thing, and not >> limited to localhost. We need to add support for encoding the virgl >> display, and send that to the client through a TCP socket. This would >> allow remote 3d to work. >> > > "gl+tcp" and VirtualGL > http://www.virtualgl.org/About/Introduction > > How the two correspond to each other, if at all? I think it means, render the guest display on the virt host+gpu, then compress it like normal video compression h264 etc, and send to the client. At least that's what I gathered from one of airlied's presentations. My confusion above was that I thought dmabuf would somehow come into play with localhost tcp connection, but I misunderstood - Cole _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel