Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
News

PI Releases DRI to XF86 74

Posted by CmdrTaco from the big-bunch-of-letters dept.
Frank LaMonica of Precision Insight wrote in to say that they have released the code to their Direct Rendering Infrastructure to the XF86 project. I saw this thing in action at LinuxExpo- very smooth quakin' going on. This is a great step in the right direction of having a fast standard 3D desktop under X. Works with Mesa's GL, and SGIs GLX.
This discussion has been archived. No new comments can be posted.

PI Releases DRI to XF86 More

PI Releases DRI to XF86

Comments Filter:

  • Re:What about GGI/KGI? (Score:3)

    by Izaak ( 31329 ) on Thursday June 17, 1999 @10:33AM (#1845905) Homepage Journal
    I don't understand what this 'waste of resources' is, running X to access 3D acceleration for full-screen games. Certainly it's true that the full power of X is not going to be used in this situation, but the DRI that Precision Insight (thanks!) has released will impose almost zero (or maybe exactly zero) overhead on the application once it is running.

    My experience has been that X does impose a small performance hit on 3d rendering. This may just be the specific driver implementations and not something inherent in X, I don't know for certain. I do suspect that the network transparent nature of X, while adding wonderful flexibility, sacrifices some of the speed you can get by having an API that talks directly to the metal. I'll need to learn more about PI's DRI before I form an oppinion.

    My main gripe, however, is with the memory that X soaks up, especially when you are running a decent window manager and/or desktop environment. Not a big deal if you are running latest and greates hardware, but I would like to write games that scale down to older hardware.

    From a philosophical standpoint, I think graphics acceleration should be handled with an abstraction layer / API that sits right on top the hardware and then the windowing system sits on top of that. Graphics can then be accessed by both X and non-X apps.

    GGI does this, and in fact goes a step farther. X itself can be used as a visual target by GGI apps. GGI can sit both under and on top of X, and apps transparently figure out what enviroment they are running in. When I run my game engine, for example, GGI automatically figures out if I am in X windows or on the console and loads the correct visual target automatically. I did not have to write code for this, it is a built in part of GGI's functionality.

    I guess what I am saying here is that, from an architectural standpoint, GGI rocks. It is designed to be very portable and flexible. Writing GGI apps is a breeze (much easier than DirectX in my oppinion). I encourage anyone writing highly graphical apps (such as games) to check it out.

    Thad

  • I think if you go to the www.nvidia.com site there is a faq, probably be able to find a mailing list from there, I would suspect.
  • I don't see the point in thinking of desktops as spacially positioned. I don't move left or right to get to the next desktop, I hit Alt-Fx (or whatever). I like to think of the desktop I switch to as replacing the current one and the current one just disappears. I don't care where it goes as long as I can get it back by hitting one of my key combinations.
  • Exactly. Now, where do we get these textures from? Does an X server keep some sort of cache that could be shuffled off into texture memory?
  • I don't know where you got the impression that AGP textures sit in system memory. Even in the very latest 3D boards they use onboard texture ram. You may get system memory textures with SGI hardware, but I for one can't afford SGI hardware.

    Also, the problem I was referring to was a problem with X, not with hardware. X can clip and draw 2d rectanglar windows, nothing more. It can't work on windows with perspective. You could possibly do some very very nasty hacks with XShape, but there would be horrendous performance.

    Remember X uses the principle of windows within windows, each window a 2d shape with a clipping area. You simply can't force a 3d interface into this model. You'd need a completely redesigned system that knew about depth, had 3 coords for a point, etc. This is because the root window and the window manager both use X as well: they aren't special cases which get exempted from the rules.

    In other words, your idea is fine, but it doesn't mesh with the reality of the situation.
  • You might want to have a look at GDK/GTK+ and probably Imlib, since these libs are very portable and hide a lot of the basic X programming from you while providing you with a nice cacheing mechanism for pixmaps.

    See http://www.gtk.org for GDK and GTK+
    and http://http://www.labs.redhat.com/imlib/ for Imlib.
  • You might want to have a look at GDK/GTK+
    and probably Imlib, since these libs are
    very portable and hide a lot of the basic
    X programming from you while providing you
    with a nice cacheing mechanism for pixmaps.

    See http://www.gtk.org for GDK and GTK+
    and http://www.labs.redhat.com/imlib/ for Imlib.

  • FBDev/XF86_FBDev and OGL accelerated X (Score:1)

    by Anonymous Coward
    What is the likelyhood of this working on top of the Kernel Frame Buffer? It strikes me as conceptually possible with future versions of FBDev which will supposedly include some degree of acceleration to run XF86_FBDev on top of the accelerated FBDev which would remove any need for multiple X servers to run on various hardware with the implementation of a modular driver on the FBDev level. The upcoming release of XF86v4 may address this issue by implementing modular binary (loadable module ?) drivers, this could also be done on the FBDev level possibly using compatible driver interfaces allowing developers and vendors to release one version of a driver and more options to the end users!!!

    If the PI DRI could happily coexist with this environment it could greatly ease X and X w/acceleration setup to the point of being almost trivial

    With an accelerated FBDev GGI could also use that as the target achieving hardware acceleration for fullscreen and (X-)windowed apps. Would GLX have to be ported to XGGI? This would theoretically make hardware acceleration available on any linux platform regardless of hardware as long as the FBDev was available for its hardware.

    I suppose at this point I would have to call out to any coders/hackers interested in this idea to get cracking at the FBDev code as I have no idea where to start implementing something like this and have been trying to figure it out for a while now. (I am sick of waiting for someone else to do something that might never happen.)

    --cable
    (behind a firewall does anyone hear your screams?)
  • Posted by stodge:

    What product are you using for drawing the graphics? I'm in Air Traffic Control systems, and I've seen two products that seemed reasonably quick for Linux for radars/situation displays - Intermaphics (Gallium) and ODS (Orthagon). You won't get the same graphics performance in this when comparing Linux to NT because the graphics subsystem I believe is in the Kernel in NT. I saw proof this.

  • Does this mean I'll finally get to use a version of enlightenment that lets me push and pull windows further and closer to me?
  • Quite possibly. You might even be able to spin a window around while working on it.

    The problem is your input device. Mice are horrible 3D navigation tools, and using a combination of mouse/keyboard to navigate your desktop probabally won't go over that well. Besides, who really needs a 3D destop anyway? :)
  • 3D desktops are required in the field of dinosaur DNA cloning. We will never be able to achieve much higher status in cloning without 3D desktops, as JP proved long ago.
  • "I leave about 20 windows open on a given desktop sometimes..."
    Doesn't this defeat the purpose of having about 8 virtual desktops available to you?
    ..and I really, really want to try the SGI 3d interface, that looks tight.

  • At a minimum, I would like to be able to grab the edge of a window and lift it up on end to see what's underneath. This could be done with a separate mouse button or something.

    I leave about 20 windows open on a given desktop sometimes. It would be really useful for quick peeks. Also, a wide window at an angle might still be readable/editable and could co-exist side-by-side with another. I know all of these issues are managable in other ways, but it would still be cool...
  • At least in Enlightenment, and probably most other window managers you can have *huge* numbers of deskstops both vertically and horzontally, as well as several stacked on top of each other... Think of it as Z layers of X*Y desktops.
    ---
    Ilmari
    Remove the capital letters from the e-mail-address
  • You guys Rock! Thank you for your Generous contribution.

    I know its a work in in progress, but now this sets the stage for some killer 3d Apps.
  • Check out the linux driver faq at www.nvidia.com. The nvidia drivers use glx, which will be way faster with the DRI in place.
  • Provided you have the right version of Irix, of course :-)

    SGI's 3D Filesystem Navigator (fsn) [sgi.com]
  • Sometimes I find the desktop "shift" to be too disorienting for some things. It also doesn't adequately address the "browsing the web while keeping track of various compiles" problem.

    I also nest netscape windows like crazy. 20 was probably an exageration... most of them are minimized. I like to leave the main page up and just open alternate windows to view the links. That way I can bring the main page forward and continue reading it as the other page loads.

    I know my personal style is a little wierd, but I've wanted windows that I can lift the edge of for years and years. Long before it was even remotely feasible.
  • Everyone notice the blurb on PI's website thanking Red Hat for funding the DRI project? I'm not normally a big Red hat booster - Debian is more compatible with my preferences - but I have to admit that funding this kind of work is a very Good Thing for linux, and I think it's important that Red Hat gets some recognition for their positive contributions. This is the plus side of having more big-business (read: money) involvement in Linux.

  • What about GGI/KGI ?
  • PI, you guys Rock! Thank you for your Generous contribution.

    I know its a work in in progress, but now this sets the stage for some killer 3d Apps.
  • The first step in making the nVidia (or any other driver for that matter) work with the DRI is to write a 2D driver for the new XFree86 architecture. As far as I know, this hasn't happened with any of the Riva stuff yet.
  • I'm very hapy with all the stuff going on
    on Linux about 3D/mesa/GLX/...

    But I have a question about 2D graphics on X.
    Is their any good (open) API for doing 2D
    graphics (and imaging) on X ?
    X iteself is rather basic in it's functionalities,
    and is painfully slooooooowwwwww.

    Here at my job we're doing radar simulation.
    We use off the shelf PC, Xwindows, Solaris/Linux.
    But the drawing are way too slow. The clien-server
    stuff, packaging of the data slow everthing down.

    (Understand that we run locally, DISPLAY=:0.0
    so that we use shared memory instead of network
    stack).

    Maybe we don't use correctly X ?
    anybody has pointers ?

    thanks
    Pascal.


  • How 'bout a 2nd 'mouse' which is really just a small cluster of programmable keys, allowing you to perform 2-handed mouse/kybd manipulations (ala quake +mlook) without using the actual keyboard.

    I know, it's yet another piece of crap to clutter up the desk. Maybe a footswitch to toggle the mouse between 2/3d?

  • Good question. I would like to see 3d accel for full screen / non X targets. Being forced to run X to access 3d acceleration seems like a waste of resources when all you want to do is play kickass fullscreen video games. The ggi3d project seems to be making progress (thankyou Jon) and hopefully these open source drivers will help. After I finish my ggi2d accel contributions, I might rejoin the ggi3d effort.

    The recent contributions from video hardware vendors really has me stoked. Linux now has the potential to be a killer gaming platform... and I will be able to totally dump windows. :-)

    Thad

  • That's exactly my sentiment as well. The mouse wheel would be perfect for a 3D window manager. No need to minimize windows, just zip them into the distant Z direction using the mouse wheel. Control/Shift-Mouse wheel and you could *move* through the Z direction, eliminating the need for virtual desktops. Kind of like a first person 3d shooter game, except the walls would be your xterms ;). Some mice have two wheels and you could use the horizontal one to spin the window around the Y axis or whatever.

    I've actually met a guy at the local LUG that wrote an extension to X that allowed for 3D windows (you would use a combination of keyboard/mouse to move the window in the z direction), but it usually crashed within a few minutes and was dog slow :(.

  • From a philosophical standpoint, I think graphics acceleration should be handled with an abstraction layer / API that sits right on top the hardware and then the windowing system sits on top of that.

    Just a general note about something that's not well-understood outside the OpenGL community: OpenGL is a hardware abstraction API that's designed to be the lowest-level interface to graphics hardware. It might seem large compared to common 2D APIs, but in fact it barely covers the hardware functionality available on PC graphics cards that will be shipping by the end of this year. (In fact, in a number of cases it has already been necessary to extend the API to cover special features in existing hardware.)

    The DRI is intended to give OpenGL direct access to hardware that also supports X, without the overhead of another driver interface layer. If one were to attempt to create such a layer, it would necessarily be about as large and complex as OpenGL, and that's not a win with respect to software development effort or performance.

    Of course it is possible to use OpenGL without X. In such a case you might not need a DRI, because OpenGL might be the native graphics interface. That's beyond the scope of current projects, but might be quite reasonable for a future project (putting Linux and OpenGL onto a console-class machine, for example).

    In the meantime, Precision Insight's DRI is intended to solve the specific problem of providing high-performance OpenGL without compromising compatibility with X. The end result should be excellent -- not only will it be possible to play OpenGL-based games like Q3A, but it will be practical to use OpenGL to accelerate graphics operations that have no support in X today. (Consider using OpenGL hardware-accelerated alpha blending, stencilling, and texturing in Enlightenment.)

    Allen
    (Former OpenGL guy at SGI, now project advisor at Precision Insight)

  • I've actually been itching to upgrade my primary workstation to kernel 2.2 so I can play with fbdev. I haven't been willing to do it while I'm in the middle of a book project; I can't afford the downtime. The project is almost finished, though, so I should be on 2.2 before the month is out. Then I will start playing with 2d acceleration under fbdev.

    Ah, the joys of hacking on linux code! :-)

    Thad

  • Mice are pretty horrible for 3D, granted, but I kinda like my logitech trackman marble+ trackball...

    It's got the trackball for 2 axes, and the mouse wheel for the third. Any intellimouse, of course, has the same wheel , but the marble+ "feels" pretty good compared to the mouse(this is entirely subjective) X calls the mouse wheel the z-axis - as in ZAxisMapping 4 5 in XF86Config to get the mouse wheel working in the first place.

  • GL/X looks a lot better than softx (Q2), but is still not terribly fast. Fortunately, it's open sourced. The release notes advise against using with Q3 (probably too slow). The direct rendering will speed it up somewhat though.

  • Does this mean I'll finally get to use a version of enlightenment that lets me push and pull windows further and closer to me?

    Possibly, but it'll have nothing to do with the direct rendering code. A window in X11 will still be 2D. The direct rendering code simply means that GL code can render directly into a 2d window, so you bypass lots of copies and buffers that normally get in the way and slow you down.

    A windowmanager could potentially use direct rendering to blit into the root window, but X11 applications will still need 2d windows within the root window. So spinning windows or windows with perspective could at best be visual hacks in the root window, not real windows you can work with.

    What direct rendering does mean is that there is no point in having SVGALIB applications or GGI3D games. The X11 solution will be within 5% of the same speed but will work with less effort, will be tightly integrated with XInput, will support a much richer drawing API, and will be network transparent with no effort (GLX to remote terminals really is impressive; imagine playing GLQuake on a server which is sitting in the next room).

    For people who need that last 5% of performance and can't bear the thought of X11 using it, don't forget to turn off Linux when you start your games either, because it's chewing about 5% in lots of places too (disk, scheduler, buffer copies for the audio, etc).

  • I would like to see 3d accel for full screen / non X targets. Being forced to run X to access 3d acceleration seems like a waste of resources when all you want to do is play kickass fullscreen video games.

    Have you ever actually measured the overhead of X11? I don't mean have you watched your disk swap while starting up Enlightenment and GNOME and fifty xterms and a 2Mb JPEG background and backing store because it's "kewl" and ten thousand fonts (because you obviously need ALL the Type1 and Speedo and TrueType fonts), crying while 128Mb of ram suddenly becomes "not enough".

    I mean have you turned off all the superfluous fonts, started up an X11 server, not loaded silly background images, started a single non-bloated client (which neatly rules out xterm), and then used a decent memory analysing tool which shows actual usage just by that application (remember a lot of tools show you a total which includes the shared glibc libraries, which is RAM you wouldn't get back by killing the X server).

    It's about 1500kb on my machine. Not a great deal of overhead really. Especially seeing as that for this 1500kb you get scaled fonts, hundreds of drawing primitives, proper clipped windows, XInput handling, authenticated access, and remote network access.

    Now if you want to argue that existing X11 is slow because you're drawing down a pipe, I don't disagree. Fortunately, that's what this Direct Rendering Interface thing is all about! It avoids the overhead caused by the X11 pipe by not using it. In other words, there's nothing wrong with using X11 for a game, not with DRI and DGA. There simply isn't as much overhead as the (uneducated) would like to believe, and X11 isn't that much of a resource hog (not compared to similar solutions).

    Remember there's more to a game than just fast graphics. You also need good input device. The GII project is trying to address this, but XInput is here now, and it isn't all that bad, and it's very well integrated into X11.

  • To add to that info, hw accel is available for the VooDoo(Graphics,2,Rush,3) chipsets.
    sure, its binary-only, sure, its glx only, but its quite playable for me in quake2 with a celeron @ 450 and a v3 2000 agp.
  • Seems to me that the mouse wheel (which I love) could do that job quite intuitively. Wheel up to push, wheel down to pull.

    Well, actually, the wheel is better used for rate-of-climb control... you can grab with the left button, then use the mouse to drive around in 3D space using an Ultima-Underworld style control system, towing your 3D objects with you. (I've been doing it for a few years now:) Err, that's if you want to fly around inside your windows. If you want to sit in one place and pull them around, then when you want is thumbwheel towards you for pull and away for push, leaving your fingers free for grabbing.

    BTW, flying around inside a windowing system is LOTS of fun, once you've done it you'll find 2D graphics kinda dull...

  • GGI is your best option -- it works under console (fast), X (okay), and other Unixes.

    -Billy
  • I think this is beeing worked on. If you look at the FAQ that came with the recent release of XFree/GLX stuff over at Nvidia you will see that that release is just to hold everyone over while XFree 4.0 comes out. I am very happy that I have a TNT (and a voodoo 2). Nothing can stop me now.
  • But I have a question about 2D graphics on X. Is their any good (open) API for doing 2D graphics (and imaging) on X ? X iteself is rather basic in it's functionalities, and is painfully slooooooowwwwww.

    This might not be the answer you are looking for, but I've been working with accelerated 2d graphics under GGI, and I have been very impressed with the speed of the X target. I am getting about 12 frames per second with my diablo-style game engine. Each frame draws about 400+ transparent blit operations with an average image size of about 50x30 with a 16 bit color depth. Note that this is without using any true hardware acceleration, just direct video memory writes and some page flipping to keep the animation smooth. The trick is to hold your images in non-visible video memory and transfer it directly from there to the screen (much faster than hitting the bus). Add hardware accelerating blit to the equation, and the animation should be scorchingly fast (I predict in the 60-80 frames per second range).

    The side benefit to using GGI is that apps will run both in an X window as well as in fullscreen mode. Interestingly, running unaccelerated fullscreen is only a little faster than running under X (13 frames per second). That should improve as the 2d blit code comes along.

    Thad


  • Because human arms, as was shown eons ago with light pens, don't like being held elevated for long periods of time.

    It might be a cool idea, but try holding your hands up front of you and moving them intracately for an hour. Imagine 8 hours of that. A day.


  • I don't think so, at least not this way. For you to do something like that with OpenGL you would have to have a lot of memory. You would of course have to have just as much memory for the actual screen display (1024x768x24bits or whatever) plus each window would have to be a tecture (a very finely detailed one at that). So each window would have to be in memory twice. Then there's all that other stuff, like Z-buffer, that I think takes up memory but I don't know anything about. I recall reading something a year ago or so explaining how we were orders of magnitude of memory away from having working 3d desktops. Of course, we probably do have orders of magnitude more memory now. That SGI thing, on the other hand, doesn't look like a conventional window manager, so who knows how they implement that.
  • I don't understand what this 'waste of resources' is, running X to access 3D acceleration for full-screen games. Certainly it's true that the full power of X is not going to be used in this situation, but the DRI that Precision Insight (thanks!) has released will impose almost zero (or maybe exactly zero) overhead on the application once it is running.

    On the other hand, using X and the DRI will allow your application to coexist happily with the rest of your graphics programs. Another advantage of the DRI is that they are addressing security and hardware locking issues.

    Now, don't get me wrong, I'm incredibly grateful to the gamers -- they have encouraged hardware manufacturers to create truly exciting graphics boards, and we in the visual effects community have been riding on the coattails of their collective economic might. I would humbly request, though, that you attempt to write to a X Windows-based standard, even though it doesn't seem to be the obvious thing at first. Don't foreclose on the future of your game applications by writing to a restrictive standard today.

    thad
    -- thad@hammerhead.com

    p.s. check out the papers under
    http://www.precisioninsight.com/piinsights.html
  • Programs that don't use X don't need a direct rendering interface. A DRI allows a program to bypass X and write directly to the graphics card. Anything that doesn't use X doesn't need to bypass it. But, the theory involved and littles bits of code might be useful for, eg., berlin.
  • >write a 2D driver for the new XFree86 architecture. As far as I know, this hasn't happened with any of the Riva stuff yet.

    You're talking about the XF86 4.0 architecture, right? The current 3.3.1 stuff has plenty of good support for nVidia, I used to run a Riva 128 and recently swapped in a TNT2 and the 2D X server is great.

    BTW, there is a development Mesa/GLX for nVidia project underway (was mentioned in /. a couple weeks ago). Looks like this is moving forward at a pretty good pace. :-)

  • For people who need that last 5% of performance and can't bear the thought of X11 using it, don't forget to turn off Linux when you start your games either, because it's chewing about 5% in lots of places too (disk, scheduler, buffer copies for the audio, etc). Can you believe I'm actually feeling nostalgic for DOS? :)
  • > The current 3.3.1

    ACK! Meant to say 3.3.3.1 - of course :-/

  • Well, I may be a bit bias, since I have a TNT, but the way I see it, nVidia seems to be the most commited to the linux community. They make very high quality chipsets and are the hottest graphics company out there, so the commercial muscle out there will be behind nVidia getting those drivers to the masses. I dont know too much about Matrox, but I am gaining respect for them also. But at this time, my choice for a good high quality 3D solution would be a TNT2 card. Might I suggest Hercules' Ultra TNT2 cards (http://www.hercules.com)
  • You don't understand DRI. It lets your app talk directly to the hardware, the X server is not directly involved. The main overhead with DRI is the memory usage of the X server (which is not nearly as bad as people seem to think. Keep in mind that the server is mmapping the WHOLE video memory into its address space, so if you have a 16 meg TNT, it makes X look HUGE, when it is in fact merely large). As for D3D, at least when I was writing apps with it, the overhead was horrible, because of those damn execute buffers. Then John Carmack saved the gaming world from the abomination that is D3D by using OpenGL in Quake, forcing 3D card makers to support it. It really is a vastly superior standard.

  • X (Score:1)

    by Trepidity ( 597 )
    Are you sure you want to use "X," "fast," and "standard" all in the same sentence? You might as well go ahead and say "Windows never crashes" as say "X is fast."
  • I'd been following PI's plans for a while, and I'm indeed pleased to see they've punched in a milestone. CG freaks here know that GLX is an important OpenGL extension, don't we? And of course it'd be the clean way to code 3d apps, making use of your hardware.

    Now we can start coding some 3d apps, demos, games. Where was my OpenGL book?


  • I have a question to add:

    I currently have a Matrox Millenium G200 (great 2D card), and a rather old Voodoo 1 for the 3D stuff. I want to upgrade my 3D capabilities soon, so I'll be looking a new card. In light of recent events, 3DFX is no longer an option :-)

    Now, both the G200 and the nVidia TNT2 are 2D/3D combos, right? From what I've read, the TNT2 is a much better 3D card than the G200, is that the case?

    Sooo, should I buy a TNT2 and get rid of the G200? Or is the G200 going to be sufficient? Let's assume performance is more important than cost for now, which should I go for?
  • I'd always thought that OpenGL rendering pipeline mimicked SGI's gfx hardware. :) Of course the OpenGL API is designed to give the maximum performance and still have you write portable code. Although the number of OpenGL features, extensions (and some SGI oddities) make it a bit large, I think OpenGL is the *ONLY* decent low level graphics API that lets you code *realtime* 2d/3d graphics; especially if you're not going for a software renderer. [it's okay to forget about DirectX ]

    I'd checked the design documents when PI released them and they did seem reasonable. Lacking only a few features (at least at first release), the GNU/Linux platform is going to be excellent for 3d. We'll be seeing a lot of catchy 3d stuff: modelers, games, demos, window managers, etc. I think that the GL support in GUI toolkits will just make it better (like the one for GTK+)...


  • A windowmanager could potentially use direct rendering to blit into the root window, but X11 applications will still need 2d windows within the root window. So spinning windows or windows with perspective could at best be visual hacks in the root window, not real windows you can work with.

    I disagree. If the 2D/3D integration is done properly, the 2D X output from an application should be mappable onto a 3D texture. AGP textures in system memory could made that blindly fast and fairly transparent to the OS and X applications. Just draw the X output to this virtual frame buffer that is mapped to a 3D texture (or maybe *textures*, depending on the 3D hardware texture size limitations). Once that mapping is done, the 3D hardware can rotate, scale, and shade that window as easily as anything else.
  • As long as the discussion is focused on X, 3D, and video cards and such, I'd like someone to help me get back up to speed on some things.

    I definitely don't want this to turn into a chipset war, but a fast summary of who's making what, whose drivers are being open sourced or will be (3dfx, nVidia, Matrox, etc.), the state of 2D support and potential for 3D would be very helpful.

    Mostly because I'm budgeting for a new system later this summer (granted, the pace of things may make forecasts difficult) and I'd like something rock-solid under 2D and hopefully with a bright future as far as 3D is concerned.

    Thanks for any offerings.
  • BTW, there is a development Mesa/GLX for nVidia project underway (was mentioned in /. a couple weeks ago). Looks like this is moving forward at a pretty good pace. :-)

    I'm curious where I can find information about the current status of the NVidia driver...I'd love to be able to play Q3A at better than 400x300 resolution and with everything turned off just to make it playable.

  • Seems to me that the mouse wheel (which I love) could do that job quite intuitively. Wheel up to push, wheel down to pull.
  • You're talking about the XF86 4.0 architecture, right? The current 3.3.1 stuff has plenty of good support for nVidia, I used to run a Riva 128 and recently swapped in a TNT2 and the 2D X server is great.

    Yeah, the DRI stuff only works with 4.0 architecture. The nVidia GLX drivers are based on the G200 work that has been going on for some time. There is a G200 driver for XFree86 4.0 so I would expect the G200 to have DRI support before any other card unless PI is actually working on doing a driver for another card themselves.

  • Thanks to Everyone Involved!!! (apologies to RH and SGI!
  • I definitely don't want this to turn into a chipset war, but a fast summary of who's making what, whose drivers are being open sourced or will be (3dfx, nVidia, Matrox, etc.), the state of 2D support and potential for 3D would be very helpful.

    nVidia seems to be committed to supplying an XFree86 server, not just binary but also source. At this point they have a server that will do 16bit color with hardware accellerated GLX (no direct rendering yet). There is also a very good Matrox G200 GLX XFree86 server where most new development is happening. The nVidia server is based on the work done with the G200 server. DMA support is being added right now and will make the transition to PI's DRI smoother (John Carmack has been doing a lot of the DMA work for the G200). As soon as we can squeeze Intel for more AGP info we'll be able to take advantage of AGP texturing as well. At this point there is no support for any of AGP's enhanced features, it is just another PCI interface as far as the driver is concerned.

    As for other cards, you can probably expect support for any new nVidia cards and the new Matrox G400 as well. It would be nice if 3DLabs showed some support for the Permedia 3, I think all they have given XFree86 is the 2D specs, no 3D. We'll see how things pan out in the next 6 months, there is definately growing support from a number of manufacturers.

  • Argh! It requires 5.3 and I have Irix 6.2.

Slashdot Top Deals

There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann

Close