Messages in this thread | | | Date | Mon, 8 Feb 1999 23:41:28 +0000 (GMT) | From | Paul Jakma <> | Subject | [OFF-TOPIC] Re: Linux Graphics Architecture (format fixed) |
| |
On Mon, 8 Feb 1999, Shawn Leas wrote:
You still want to go the way of DOS. I remember downloading a JPG veiwer called QPEG, and it had video drivers bundled with it.
Sounds a little like X, eh?
then again, use the right tool for the right job, and don't let principles get in the way of practicalities.
Is the hassle of implementing full-blown, accelerated, concurrent access, graphics drivers in kernel worth the effort?
how many people really need to have several processes concurrently writing to the graphics hardware? As it stands i can think of only two: X and a direct render graphics layer - which would have to co-operate with each other to be of practical use anyway.
[X is the de facto UNIX graphics standard for the foreseeable future, for better of worse. {better imho}.]
If it was for a single platform with a reasonably limited range of graphics hardware - then maybe yes. But for an OS that covers so many platforms? and those platforms cover how many weird and wonderful different graphics hardware?
And which cards are capable of what? How do you present a uniform interface? How would a uniform, rich, in-kernel, 3d & graphics implementation run on my P133 with Trident TGUI graphics card? Keep it too simple and you're wasting the more exotic hardware.
So perhaps it's best to let the kernel stick to a limited knowledge of the graphics hardware, so that it can always clean-up if needs be. And let the higher level stuff sort it out between themselves as to what they want to do.
If needs be, some basic functions can always be migrated from the higher level into the kernel. but let X and co worry about concurrency and arbitration and things like that. The kernel has enough of that kind of stuff to worry about already.
Eg, DEC faced this issue when they tried to go head to head with SGI with their PowerStorm graphics card. Their solution was to implement direct rendering with the X server handling concurrency issues. X can then arbitrate between multiple X protocol and direct render clients, as it sees fit. Only that with direct render clients the X server doesn't need to do any rendering work, the direct render client and the X server just need to set things up via the X protocol.
X is already an arbitrator, why reinvent the wheel when it can just be extended to arbitrate between more types of clients?
(Direct render clients can be anything by the way. Doesn't have to be OpenGL.)
This way, we keep a standard and already uniform graphical interface, X. And we can write extensions to it to support a uniform high-performance graphics layer, "direct render" for more advanced graphics cards. And we don't clutter the kernel with highly complicated code that could run in user-space.
[eg: why can't the kernel do sound mixing? - so that 2 or more processes could write to /dev/dsp concurrently and produce a real mixed sound? the implementation itself exists.....]
regards,
Paul Jakma.
(perhaps this thread should be on another list.).
-- Paul Jakma paul@clubi.ie PGP5 key: http://www.clubi.ie/publickey.txt ------------------------------------------- Fortune:
[FORTRAN] will persist for some time -- probably for at least the next decade. -- T. Cheatham
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |