[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH 2/2] Virtual frame buffer: user space backend
On Fri, 07 Jul 2006 23:50:32 +0100, Christian Limpach wrote: > On 7/7/06, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote: >> Since the best we can do is page granularity (for now), why not just >> have a bitmap represent the dirty pages? > > Doesn't your virtual framebuffer already support 2d operations? Nope. X won't even bother using the interface. Plus, serializing 2d ops is quite challenging when dealing with a shared buffer. > Also, the > cirrus driver emulation in qemu already supports copyrect. I know, I added support for it. It was really painful to get right too since the vga memory has to be flushed before the copyrect occurs (and the system has to disallow more writes until the copyrect completes). It's going to be even more painful in Xen since the cost of that serialization is going to be greater. >> Instead of switching bitmaps, why not just have the backend and frontend >> share a bitmap and do atomic get/sets on it? > > Because we'd like to avoid atomic operations. Why? That seems odd to me. >> I think the key point is to have the bitmap represent linear regions of >> framebuffer memory instead of logical rectangles within the current >> resolution. > > Well, I don't agree ;-) Because we want to transport 2D redraw > information from the frontend to the backend. So 2D information is very useful, especially for VNC. I think for Xen though, we may need to abandon the shared framebuffer completely and develop a lightweight framebuffer protocol. The idea would be to push the dirty'ing analysis to the frontend and have it communicate data over a higher bandwidth ring queue. This avoids having to deal with synchronizing the shared framebuffer for 2d ops. This is quite a bit different from the code today though. What do you think about getting rid of the shared framebuffer altogether? Regards, Anthony Liguori > christian _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |