>Ramon van Handel wrote:
>
>> > Using synchronous updates instead of async ones may be
>> > even slower: there can be a *lot* of accesses to the video
>> > memory, and causing a full VM switch for every byte written
>> > might well be much slower than just reading the whole
>> > thing say 50 times a second.
>>
>> Uh... hang on. I never mentioned this. What are you
>> referring to, exactly ? I said
>
>Ah, I seem to have mis-read what you were saying. Sorry.
>
>[snip mapping host frame buffer]
>
>I wasn't thinking of this at all; at the current stage, IMO we
>shouldn't touch the real host hardware directly in any way.
Of course not. I'm just ranting about long-term goals. Eventually,
we'll want to support 2D and 3D hardware accelleration in the VM
so people can play games... after all, what else would you want to
use windows for anyway ? ;)
Of course, such a method is only suitable in certain cases (full-screen
or special guest drivers). It's no substitute for full VGA emulation.
>I was just talking about possible ways to implement emulated VGA
>hardware, either by asynchronous means (read out the guest frame
>buffer periodically) or by synchronous means (trap guest access
>to the frame buffer, like we trap I/O access -- this is how Bochs
>does it AFAIK).
Okay, as I said, that's fine for now. Just planning ahead.
>> (2) that you can use the dirty bit to check, whether
>> the guest wrote to the framebuffer memory.
>> There's no reason that this should imply mapping
>> the FB read-only... to the contrary, it avoids it.
>
>If you do in fact map the host frame buffer, you don't even *need*
>to check whether it was modified -- it is already displayed.
This time, I was referring to an emulated VGA :)
>You
>could use this information to help the asynch frame buffer emulation,
>however, so that you can skip updating the video display if the guest
>didn't touch the (emulated) guest frame buffer during the last tick.
Exactly, that's what I meant.
Getting back to updating with the timer: currently, you set a timer at 100Hz.
However, linux programs the PIT at 100Hz, so that would imply that the VGA
gets updated on every single timer tick. That is of course unheard of (it would
lock up the system !!) so we're just fooling ourselves. I played around with
it a bit and it seems that now too, the update freq varies heavily with the
system load. What I don't like about the timer is that with a fixed frequency,
you're either over-updating or under-updating: under-updating, if you set the
frequency too low; over-updating, if the frequency's too high: ideally, you want
to update once, and only once (except if the FB's not dirty, in which case you
don't want to update at all), after each quantum the user program got. There's
no way of guaranteeing this with a timer, you may update twice or three times
that way, certainly when the frequency's high. There's no way of guaranteeing
this with a separate thread either; however, assuming that both threads (user
thread / video update thread) have more or less the same processing load (I
assume the time spent in the kernel module is billed by the linux scheduler as
I/O (system) time, not compute (user) time) the two threads would be treated in
more-or-less round-robin fashion (they're both I/O bound so would probably get
the same priority), which would be a good way to achive our goal.
What do you think ? Kevin, what are your experiences with a timer-driven
update system ? Of course, with BOCHS, it probably doesn't matter all that
much either way because the CPU emulation is limiting factor...
-- Ramon
