On 8/22/06, Lourens Veen <[EMAIL PROTECTED]> wrote:
What is the job of the kernel with respect to graphics?
The job of the kernel, always, is to provide abstraction from the hardware, as well as insulate the hardware and other applications from badly behaved applications. There are certain aspects of graphics that deserve to be in the kernel as much as, say, the TCP/IP stack. "In the kernel" is perhaps a bit ambiguous, because you can have a microkernel with services or Linux with drivers in userspace. Perhaps we should say "via the kernel." Many aspects of the abstraction only SEEM to be in the kernel. For instance, glibc provides a portable wrapper around the kernel ABI. A lot of this is done for efficiency reasons so as to avoid actual kernel calls as much as possible. We can apply this to graphics. The only things that MUST be in the kernel have to do with security, interrupts, and SOME aspects of DMA. The rest can live in userspace libraries for performance reasons.
What does the kernel need itself in terms of graphics/user interaction?
Minimally, it needs a way to display boot messages and otherwise interact before more sophisticated services have started. I like the idea of moving the virtual console and other graphics management mostly into a daemon.
What abstraction should the kernel offer to userspace?
That's a hard question. Here are some groups of facilities I can think of right off: - Setting resolution/depth - Allocating virtual consoles - Low-level rendering (2D, 3D) - Graphics memory management - Timing facilities (wake on vertical blank interrupt, etc.) - Zero-copy mechanisms Other facilities would sit on top of that. For instance, OpenGL offers more abstraction for 3D. The API would provide hooks for various sorts of 3D processing, and the OpenGL library would query for which ones are available, which ones are emulated well by the API's infrastructure, and which ones are best done by the OpenGL library. X11 is similar in this regard. The API would have no concept of "windows". X11 would use the API for the low-level rendering.
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.
Once we have some good solid argumentation on this, we can find out what the current situation is, what experimental work has been done, and how we could move from the current situation to a better one, in small steps. And then we can worry about userland too. But please, one thing at a time.
I feel like I'm too influenced by the discussions started by Richard. I'm probably not being abstract enough with my response. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
