> > > > AFAIK, people more knowledgable people then me on 3d (ie Keith Packard) > > all seem to agree on that transfering the commands to render would be > > more expensive. IOW adding 3d support to Spice would be not really useful. > > afaik, opengl has been designed originally with remote rendering in mind. > > I am no opengl expert, but it probably very much depends on the kind of application (Alon reported us about Android apps remoting being fine). Wouldn't glx gears be fine too? ;) I think the upcost is pretty big in general, because of upload of textures and data arrays which are not very well compressed in raw protocol. Probably a remote protocol, like spice, could help compress those (and cache on disk!). Then result can be read back in some applications, but that is not always the case (even rendering to texture and composition could be done remotely). Usage of readback is discouraged in general. Imho, it could be worth some experiments. But current local only approach is necessary anyway, and the server rendering approach could be complementary too. IIRC some high-end nvidia gfx cards (which can be partitioned for virtual machines) can encode the guests display as H.264 stream in hardware. Given that there are use cases for hardware assisted video encoding in the consumer space too (beam your android tablet display to the smart tv over wifi) I wouldn't be surprised if video encoding support is commonplace in gpus in near future (maybe it even is there today). That'll make sending a H.264 stream as display channel an interesting option. Should be a reasonable efficient protocol, with the ability to offload alot of the actual work to the gpu on both server and client side. cheers, Gerd _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel