Tomas Carnecky wrote:
David Bronaugh wrote:
Another option would be to design a generic, more low-level wrapper for graphics hardware. In my opinion this is a huge undertaking (ever read chip docs? You try integrating 3000 pages of information (that would be around 5 different chips)). However, if you think this is a good idea, feel free to do it. Just take about 6 months off from life...
That's why I think there should be a more high-level interface.
My idea is that every card creates a device node in /dev which can be openend by anyone with appropriate rights. With each device is a userspace library associated which has implemented the interface
functions (gl*). The interface between userspace library and device node
is not defined, each driver/library pair can create's own interface.
So it is possible to
1) implement everything in userspace and use the device driver only to
access the framebuffer or
2) use hardware acceleration using the device driver.
So it's possible that every driver developer can decide for himself what
to put into the userspace library and what into the kernel driver.
The only interface that is defined is opengl.
Essentially, this is what the Mesa/DRI/DRM combo do now (as I understand it; feel free to correct me).
(Actually, that's not just an idea, but my project. I've done quite a lot of work so far, now I'm looking for some opengl implementations I could use.)
[1]: even /dev/hda or /dev/sda is readable by world (at least on my box).
Which is fundamentally insecure. People can find your /etc/shadow file on /dev/hda or whatever and run John the Ripper or its ilk on it. Simple matter of using 'grep'.
Ahem.. sorry.. I mean readable by anyone who can log into the machine, not many people in my case. And I'm thinking of usual home computers, not servers. (High performance graphics cards on servers?)
I can think of applications. Think render-server with high-powered graphics card as coprocessor. I wouldn't be all that surprised to see CGI apps on the 'net using OpenGL to render stuff within 3 years (if it isn't already done). SVG can't do everything...
[2]: X isn't easy and DirectFB.. it's a bit better to use but it's still
a lot of unnecessary code around the actual driver.
Unneccesary in -your- opinion. How much have you studied it?
Just to render a nice picture using opengl (off-screen)?
You've studied OpenGL, haven't you? It's rather large. It is (as I understand it) an abstract state machine.
It's not fun to map one state machine to another. I haven't done it for graphics cards, but I've done it for network protocols.
David Bronaugh
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
