On 8/22/06, Lourens Veen <[EMAIL PROTECTED]> wrote:
On Tuesday 22 August 2006 22:04, you wrote:
> On 8/22/06, Lourens Veen <[EMAIL PROTECTED]> wrote:
> > How does this interact with its other tasks?
>
> Usually via other standard APIs. If we do it right, most of X11 and
> svgalib will stay the same. We'll just give them drivers that use
> the API, and those drivers would generally be very simple. With the
> graphics system a single process (per graphics device), race
> conditions can't happen, because everything is serialized by that
> process managing things.
I mean, how does providing graphics capabilities interact with the other
tasks of the kernel, like scheduling processes? This ties back in with
the discussion about the timer interrupt, and other discussions about
latency and desktop responsiveness under Linux. Apparently there is
some real-time aspect to providing graphics capabilities that makes the
scheduler part of the graphics subsystem in some way.
For graphics drawing that takes a long time, it's scheduled and
interrupted like everything else. We might give the daemon higher
priority. For the realtime stuff, it's no big deal to have a DMA
block scheduled to be issued within an interrupt handler.
For example, when watching video, audio drop-outs are worse than video
drop-outs, in terms of how noticeable they are to the viewer. So, does
providing graphics capabilities include a scheduler that wakes up a
process that is waiting for an audio buffer to empty before a process
that is waiting for a video buffer to empty, if both are scheduled to
be woken at nearly the same time?
This is beyond my expertise. I've watch LKML conversations on this
topic before.
The main idea of this question was to determine what other parts of a
kernel would be affected, or need to be taken into account, when you
change or design a graphics subsystem.
Up to now, all I can do is agree that this is a big concern that we
should try to address.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
