--- Ramon van Handel said
> >[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 ? ;)
This is why I like the idea of the Xvnc code so
much!!! I think that you can even play X-doom in it
(I'll have to try). I think that that should be
enough virtual 2D and 3D power....., maybe?
>
> 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.
We could try though........
>
> >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
Couldn't we includ some sort of cheap load monitor
type thing to make sure that the video gets updated
fast enough... or is that too much extra stuff (work
too)?
Drew Northup, N1XIM
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
