Daire Byrne wrote: > Yaniv, > > On Wed, Dec 16, 2009 at 1:46 PM, Yaniv Kamay <yka...@redhat.com > <mailto:yka...@redhat.com>> wrote: > > Daire Byrne wrote: > > current Xorg driver doesn't have the video stream/ffmpeg > heuristic detection stuff yet right? I ask because when > playing back a flash movie (e.g. youtube) the network traffic > across the spice protocol is > > The stream/ffmpeg heuristic is done by the server but it depend on > the way app render the video and how the driver transmit it to the > server. I sugget trying using madia player befor you try youtube. > > > Well I tried VLC too but it doesn't seem to be getting compressed. I > suppose the Xorg driver just doesn't pick up on the video rendering > yet. Maybe there is some debug info out of qemu-spice that reports > when ffmpeg is being used? You can turn video compression using qemu monitor command and see if there is any differance.
spice.set_streaming_video on spice.set_streaming_video off > > > In this worst case scenario of sending the uncompressed video > frames from the server to the client I see that the network > bandwidth never gets above ~10MB/s (on a GigE LAN network). Is > there a limit in the speed of the SPICE protocol across the > network? Neither the spice client nor qemu-spice seem to be > CPU limited. > > > We do not have limit on network bandwidth. > > > I was just curious why I see lots of frame drops without the > compressed video. I suppose the spice client and/or Xorg driver just > can't render frames fast enough yet so it is not the network transfer > that is causing the poor playback - it is the other way around. > > When you implement OpenGL 3D acceleration will you do it by > providing your own OpenGL libraries for the guest > (windows/linux) to intercept every GL call? (e.g. > VMGL/VirtualBox). Would that mean that every GL call will need > a corresponding SPICE 3D call? That sounds like a lot of > work/development and no doubt compatibility would be pretty > hit and miss. > > OpenGL to OpenGL is not complicated it is just a lot of work. > Compatibility will be based on the OpenGL version on the server > (Guest will see OGL version <= server OGL version), in the worst > case client OGL < selected OGL version) OpenGL will be rendered on > the server and transmit the result as bitmap. > > > Interesting. If I have a server with no 3D card (mesa) but my clients > have Nvidia cards (say) will the OpenGL commands still be accelerated > on the client and just passed through on the server? With the Theoretically yes but I don't think it will be a good idea to use software only rendering on server side. > bandwidth, speed and video memory sizes of modern graphics cards I > just can't get my head around how fast/effective it will be to dump > OGL commands down the network. I suspect that the "hosted" VM case > where there is no network between the client and server will be the > only really effective way to get good results. I believe this is what > VMWare are proposing with their Gallium3D method. It all depend on ratio between textures and commands. > > > http://vmware-svga.svn.sourceforge.net/viewvc/vmware-svga/trunk/doc/gpu-wiov.pdf?revision=1 > > For remote 3D they are just going to do serverside rendering and send > the bitmaps (Teradici's PCoIP). It just easier to implement, the target client is also factor that need to be consider. Spice design will enable spice to work in both ways Now we only need to implement it :). > > In order to get a real feel for what performance SPICE is > capable of I suppose we need to see the Windows QXL driver in > action which is far more advanced. What is holding back its > release and will we see it in days, weeks or months? > > Yes you are correct you need to see the Windows QXL. The release > of the Windows binaries was hald back by some technicalities, we > now have green light so It will be avilabe in days time frame. > > > Great! I will play with that then and wait for the Xorg driver to > catch up. > > Thanks for the info, > > Daire ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Spice-space-devel mailing list Spice-space-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spice-space-devel
