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 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? 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. Lourens
pgp9bPTLB53Vz.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
