|
| From: | Anthony Liguori |
| Subject: | Re: [Qemu-devel] Spice project is now open |
| Date: | Fri, 11 Dec 2009 13:51:53 -0600 |
| User-agent: | Thunderbird 2.0.0.23 (X11/20090825) |
Izik Eidus wrote:
On Fri, 11 Dec 2009 13:30:22 -0600 Anthony Liguori <address@hidden> wrote:Izik Eidus wrote:I should speek with the marketing guys, will be able to answer on that specific question in few days. But simple 2D Commands are just not enougth for spice. We have multiple drawing surfaces, that are depended on each other. We Dont renender untill the very moment that the guest try to read its video memory, we have video streaming, and we have cache based by the guest driver. We have private channels for stuff like keyboard, display and soon...The video streaming is an encoding heuristic though, right? The lack of guest visible rendering is interesting.The video streaming now is motiation jpeg due to patents problems.
The approach taken by THINC was to support just a YUV overlay. That gets you half way there in terms of compressing a video stream. Since most hardware provides YUV->RGB acceleration, it fits very well into existing driver architectures. For instance, VMware VGA supports YUV overlays because X has the Xv interface for this.
The other important bit is tiling. That's easy enough to support in something like VNC since it's rectangle based. The one real missing bit is tile motion. I would think you wouldn't get that with mjpeg anyway.
The other equally important piece is hardware scaling. Obviously, if you have a normal desktop resolution and are full screening an NTSC dvd, you can save a huge amount of bandwidth by supporting a scaled overlay.
I think adding both of these things to VNC would be pretty easy. I think the result would probably be better than a heuristic based mjpeg (simply because of the accelerated scaling).
Any thoughts on that? Am I misunderstanding how the mjpeg works with Spice and QXL?
What you mean lack of guest visible rendering?, I might didnt understand you
Sorry, I meant what Spice does with video memory (that it doesn't render a bitmap until the guest tries to read video memory). If I understood that correctly, it sounds very interesting. Again, I'd love to see the perf details around that.
I'm not familiar with what a "depth viewing tree". Can youelaborate?In it simplest way of working, we will take the simplest case of what it is doing: If you have application that rendered a window, and then it renendered another window on top of it, you dont want to send the commands that rendered the old window, beacuse the new commandshide the older one...Ah, this is unique to a windowing protocol. A framebuffer protocol does not have to worry about this because the OS does it for you.Not true. This is optimization for remote rendering, in physical machines we can rendner what ever we want, it take more cpu to try to use trees in order to render the right things.... But with remote machines, we dont want to stress the network, so we want to transfer just what we really need.
If the z-order of the window is such that one window is not displayed, then it's contents will not be rendered. In Windows, individual windows only receive a WM_PAINT message with the visible region. Not all apps clip accordingly of course.
For X, only windows that are visible receive expose events and again, they're given a clipping region with what is actually displayed.
By the time we get to video memory, the display server has already straightened out what portions of the screen are visible and what aren't. It will not render a hidden window and then render another window on top of it.
How well does this work with a Linux guest? To get a lot of this level of information, you have to hook in at the X protocol level (which is what NX does). Can you really do much at the X driver level?Well we have X driver, why would there be any problems with X?
A lot of the things in Spice (from a quick glance at the spec) are too high level for just an X driver. For instance, there are glyph based operations presumably for text rendering. There are also brush primitives. While X has some support for these things, it's so old and broken that in modern applications, most toolkits just render to a local buffer, and then do a draw the image to the window. That means the X server has no visibility into the fact that you're actually rendering text which means an X driver cannot take advantage of that information.
Spice driver to X (I mean from the X prespective on things) is just another display driver.
What's the performance compared to the Windows driver?
As I said, I don't have a problem with externalizing things. I think there's some discussion about how best to do that. For instance, I think we want to avoid shared library plugins as it introduces a good deal of instability into our address space.Think about qemu give infastracture to multiple librarys to use it? For example one user can use qemu with VNC, one with SPICE, and one can use qemu with diffrent private local rendering soultion (for highly fast local 3d rendering...)Well why libc is diffrent then?
libc is not a plugin. It implements very well defined behaviors that have well understood behaviors. Also, glibc generally does not crash :-) I would not want a user to replace glibc with a different libc.
Regards, Anthony Liguori
| [Prev in Thread] | Current Thread | [Next in Thread] |