Tomas Carnecky wrote:
Ian Romanick wrote:
Tomas Carnecky wrote:
The dri/drm interface seems to be quite low-level. I heard somewhere that different devices have quite different registers and work in a quite different way. If it is true that it would be better to make a more high-level interface where every driver can do it's stuff as it needs. How much low/high-level should the interface be so you get the best performance out of these many different devices and don't have to make workarounds in the drivers. I have the impression that the newest cards have quite high-level chips interfaces (supporting shaders etc.).
The design priciple of the open-source drivers is that the kernel part acts as nothing more than a conduit to shove bits into the chip.
It's the first time I hear that.
Because of that, the interface is pretty raw and varies from chip to chip. For DMA programmed chips, the user-mode driver works by filling buffers with "stuff" and asking the kernel to kick of a DMA operation with the buffer. That's why so much of the ioctl inferface is device-dependent. This doesn't make for "workarounds in the drivers", it just means that the user-mode is written to work with its own low-level kernel-mode interface.
This reminds me to XFree86. XFree86 requires root rights to run, because it accesses the hardware directly (using /dev/mem) and does other dangerous things.
I think that the device driver should avoid that and expose a nice and safe interface to the userspace.
As far as 2D goes, there's been plenty of talk about this.
As far as 3D goes, see below.
On advantage of this is that we don't have to modify the kernel drivers very often. Some of the drivers have had regular updates to the user-mode part, but thier kernel driver hasn't been modified in over a year. For us, that's a *big* advantage.
This is certainly a very unimportant thing (for me). Because all other parts of the kernel change regularly, why should the graphics drivers
not?
The way it is now works. The only other way that would work is if there were a consistent, defined interface to the driver(s) that DID NOT CHANGE. See below for why this may not be practical.
A device driver is not just a wrapper around the device which gives you access to the registers. Even the core components of your computer have a nice interface (your harddisk controller: open/read/write/close etc).
You're speaking of a generic interface to the hardware. The problem (from what I have seen) with doing this with 3D graphics hardware is that it really -is- all different. Different in design. You -could- put a whole OpenGL driver in the kernel, and that would abstract the hardware successfully, but there are a -LOT- of good arguments against this (bloating the kernel's image size by 2-3 megs would probably not be appreciated -- a LOT of bugs would get in, etc.)
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...
The device driver should expose an interface, which can be used by all
users[1] in a safe way. With the current design, you can't render into a
off-screen buffer easily. Either you use X or DirectFB. But it's not possible to use it in a easy and safe way[2].
Actually, there's been a lot of talk about how to fix this kind of thing. Memory management and mode switching is a solvable problem, albeit perhaps not in the nicest way. Nonetheless, I think the current proposals will work.
[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'.
[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?
David "I am not a DRI developer" 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
