Slashdot Mirror
XFree86 DRI on NetBSD
Dan writes "Erik Reid has been working on adding DRI support for NetBSD. Direct Rendering Infrastructure, also known as the DRI Project, is a framework for allowing direct access to graphics hardware in a safe and efficient manner. Some of Erik's work has been imported into XFree86 4.3.0 which is now in xsrc tree. He has subsequently put together a fairly large patch which compiles and works on his NetBSD/i386 1.6P system with a matrox g450. Try out the patch and give him some feedback!"
...what if anything this might mean for getting DRI on OpenBSD? Thanks.
Now give me nVidia and ATI drivers that have all the support/features under linux/BSD that you have under windows THEN I'll be exited.
Patrick Havens (Mr. 573333 to you.) Graphic Artist / Coder / Father / Journeler
Just like QT unifies the different window systems and opengl unifies various graphic systems, I think we seriously need a unified system of drivers for all *nix including Linux, BSD, Solaris if Sun sees the potential, AIX ditto, Beos and darwin. Newer OSes like Plan9 would use the infrastructure and gain support of ALL the hardware.
I'm not too sure how we could cope with not adding additional code layers slowing things down.. perhaps an M4-based system that changes the right functions in the driver code, and removes or replaces OS-specific functionality depending on the output of uname. Such a unified system would attract hardware designers who would release their driver code according to this structure to support multiple OSes, and Free Software would be the big winner here.
Ive had to move from FreeBSD to Linux to Solaris now, due to the inherent lack of tokenring drivers, or its stability. FreeBSD had only one TR supported, in alpha, and it crashed. I wish I had the option of using NetBSD. Linux has a slew of TR supposedly supported but there are some bugs in receive buffers of TR code when using it with ethernet and ipfilter. I tried tuning many things, even tried to implement my own receive buffer with additional checks. It was a bit complicated for me.
The various unixen have a collection of kernel hooks that could be used in drivers. A simple large table could be made for hooks that are similar, showing differences in naming, arguments and limitations of buffers etc. Other pointer hooks then could be made to represent and encapsulate these hooks, also encapsulating additional procedures that need to be run before/after each hook on specific systems.
Non-equivalent hooks are more difficult to use, some might need additional programming on some systems while other systems would have part of that functionality built in. For this, we gotta build trees of functionality of each driver type, say networking, graphic, input etc, for each system making a 3d graph of the functionality and working with the weaknesses of some systems making it similar to the strengths of others, makin it easy to create encapsulating hooks.
The encapsulating hooks themselves could be either C functions, pointers, or M4 macros, which would be replaced with the code of the right system just before compile time. I would go with c pointers if theres NO resulting performance hit after being compiled with gcc -O2. If theres a resulting performance hit on ANY system, I'd say we're pretty much stuck with M4 which on some systems could become too complicated to be worth it.
Pulling out all drivers from the Linux code, and FreeBSD and sticking it all into the tree, and demonstrating its working would be the end of the first phase. Establishing a proper standards group, quite possibly with posix/ansi/someotherbody would complete the second phase. After that its all sit back and wait, and just like WDM in windows, hardware makers should re-release driver codes for a more unified platform.
Apart from a major boost to Net/OpenBSD, Plan9 and others, the Linux kernel might be lightened much from todays 30MB+. Yet another issue would be driver signing and security unless the whole driver structure is downloaded with the kernel sources of each OS.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
Good luck. I had difficulty installing 1.6, when my installation crapped out with a Segmentation fault, 1.5 was more stable...
And amazingly you are still able to post with a dead brain.
http://www.projectudi.org/ Or existed, it seems like it hasn't been updated in a while.
I did some work in this, interesting environment. All drivers are source compatible across all conforming environments. If the environments have the same C ABI (say, they're all x86) then the drivers are binary compatible. Caldera actually made this their native DDI for OpenUNIX 8. There are environments for OU8, Linux, and FreeBSD, and some drivers out there. One cool thing is that the environment handles MP. All your functions are guaranteed never to be interrupted. Downside is, it's a very different environment from what you're used to, and it takes a while to get your head around.
As an aside, RMS doesn't like the environment because it makes it easier to release binary only drivers. Not only does it insulate youfrom DDI differences between platforms, but also between Linux kernel updates.
Seriously, the "BSD is dying" troll was fairly amusing in it's own trolly way at first, but it's getting really quite tired now.
Don't get me wrong, I enjoy sifting through the comments with Threshold -1, and I do I like a good AC troll now and again. But I at least like to make my trolls interesting, sarcastic, amusing, and most importantly, different.
Posting the same dumb troll over and over again is just plain dull and unimaginative. Try and find something new and unique to troll with.
Thankyou.
Interesting stuff.
Part of opensource developer psychology is exclusivity. Belonging to for instance the FreeBSD or Debian linux camp, and not developing something that contributes to the other camps especially the commercial OSes like Solaris. I think this would hinder the unified drivers. And like you said its a very different environment, its also an added layer, and what attracts developers to system/kernel/driver programming in the first place is the low level.
But I think theres a threshold beyond which people will contribute more. Project UDI will take effort to get there, including remaking previous-ly made drivers in UDI. Since Opensource OSes have much to gain from this, they should rally around this idea, especially the underdog OSes like NetBSD. I wouldnt expect Linux developers coming wholeheartedly.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
I don't know exactly... Open and Net are similar systems so maybe it will help. But are Open users even interested in this. They seem to be so security focused they don't even mind Mozilla not working... On the other hand what is the use on DRI on Net, somebody playing quake on Net? Maybe in the future we have 3D models living in every web page and DRI becomes essential...