On Wednesday 23 August 2006 14:32, Timothy Miller wrote: > On 8/22/06, Lourens Veen <[EMAIL PROTECTED]> wrote: > > > > 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.
Okay, let me rephrase that again. The abstraction contains operations. What guarantees does the system give with respect to each of these operations, and to the sequence of operations as a whole? A real-time system would guarantee that each operation completes within a certain amount of time for example, whereas a non-realtime one wouldn't. Perhaps the system guarantees that the operations are executed serially, in the order in which they were submitted. Or maybe it only guarantees a weaker constraint: that all the operations on a certain grid are executed in the order in which they were submitted. Note that this latter abstraction will still work as you would expect. Furthermore, if we delay any operations on the primary (visible) grid until the vertical retrace occurs, then you can do double buffering by simply drawing to the backbuffer, doing a flip (which would be treated as an operation on both buffers), and waiting for it to complete. Triple buffering? Perform operation on one of the backbuffers, flip it with the primary, continue sending operations on the other backbuffer. They'll bypass the flip, so there's no time wasted. There would probably have to be a way for the programme to sleep until a certain operation it issued has completed. Also note that there is now no concept of a vertical retrace. Displays that don't have to wait for a vertical retrace can simply have a driver that doesn't wait. > > 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. Indeed. The kernel maintainers are unlikely to accept any changes without having a very good idea up front of what will be involved. Lourens
pgpjYy99jeGbX.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)
