Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
GUI Operating Systems Software X BSD

XFree86 DRI on NetBSD 28

Posted by timothy from the bare-metal dept.
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!"
This discussion has been archived. No new comments can be posted.

XFree86 DRI on NetBSD More

XFree86 DRI on NetBSD

Comments Filter:

  • Can anyone then tell me... (Score:3, Insightful)

    by amarodeeps ( 541829 ) <dave@dubi t a b l e.com> on Friday March 21, 2003 @01:07AM (#5562917) Homepage
    ...what if anything this might mean for getting DRI on OpenBSD? Thanks.
    • It shouldn't be too difficult to make it work on OpenBSD, though I'm not going to do it, and I'm not
      going to guarantee anything. :)

      Basically someone that knows something about OpenBSD needs to step up and start digging in. Eric Anholt did some fantastic work in abstracting some of the code, so it really wasn't tough to make it work on NetBSD.

      - Erik
    • FreeBSD code is completely different than the other BSD's. OpenBSD's code is still very much like NetBSD's code, with some exceptions, so once it's working good on NetBSD, it should be fairly easy (to the seasoned OpenBSD developer) to port to OpenBSD.

      3D on OpenBSD? Mmmmmmmm.
    • 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...

  • *nix Support (Score:2, Insightful)

    by phavens ( 573333 )
    If you have support for one verion of BSD... It can not be hard to get it running for another version. And for that matter another version of *nix. It might just be a matter of recompiling.

    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.

  • Unified UNIX drivers (Score:5, Interesting)

    by mnmn ( 145599 ) on Friday March 21, 2003 @11:10AM (#5564740) Homepage

    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.

    • Re:Unified UNIX drivers (Score:4, Insightful)

      by CoolVibe ( 11466 ) on Friday March 21, 2003 @05:23PM (#5569277) Journal
      In a perfect world, your vision would be useful and yes, I'd vouch for it, but it's a license minefield. :-(

    • Re:This already exists. (Score:4, Informative)

      by cant_get_a_good_nick ( 172131 ) on Saturday March 22, 2003 @08:49PM (#5576330)
      http://www.projectudi.org/ [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.

      • 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 bey

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close