Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx> writes:
> Markus Armbruster, le Tue 04 Mar 2008 16:48:20 +0100, a écrit :
>> Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx> writes:
>> > Markus Armbruster, le Tue 04 Mar 2008 15:32:57 +0100, a écrit :
>> >> > In my case, I'm using PVFB to expose the stubdomain qemu display. The
>> >> > problem is that every 30ms, qemu wakes up to memcmp() the whole video
>> >> > memory with a shadow buffer so as to track changes. If it knew that the
>> >>
>> >> Wait a second! You're talking about *your* frontend here, aren't you?
>> >>
>> >> Maintaining a shadow copy in the frontend (which requires compare and
>> >> copy) to minimize copying in the backend sounds pretty self-defeating
>> >> to me. Why is this a good idea?
>> >
>> > Because in my case the domain is HVM, and I don't want to trap the
>> > writes to the video RAM since that's awfully slow.
>> >
>> >> Why not refrain from sending update messages and have the backend
>> >> simply redisplay everything?
>> >
>> > Because as explained above, I can't avoid a shadow copy.
>>
>> I imagine (perhaps naively):
>>
>> * The domU writes to a framebuffer provided by the frontend.
>>
>> * The framebuffer (not a copy of it) can be shared with the backend,
>> which only reads.
>
> Well, that's not always the case, when the guest is in text mode for
> instance, the PV shared buffer is converted from the guest text buffer.
Optimize for the common case. Which I figure is a 32 bpp framebuffer.
Anyway, compare and copy for some legacy 80x25 text mode shouldn't eat
that much CPU.
>> * If the frontend can track changes efficiently, it sends update
>> messages to the backend, which can use them to only redisplay
>> changed areas.
>>
>> Else the backend needs to assume the worst and periodically
>> redisplay everything. It is free to maintain a shadow copy to track
>> changes and minimize redisplay, if that turns out to be faster.
>>
>> What's wrong with that?
>
> Well, that was actually my next target :)
> (but for that we badly need the resize/redepth support).
We'll see another iteration of the patch soon, I hope.
> However, that doesn't solve something that still bugs me, which is
> that the VGA emulation layer wakes up every 30ms to just notice that
> the width/height/depth registers didn't change etc. even if the actual
> window is not shown.
>
> Samuel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home