Slashdot Mirror

← Back to Stories (view on slashdot.org)

3dfx to develop DRI for linux

Posted by Hemos on from the more-support-coming dept.

skroz writes "At Linux world today, 3dfx announced plans to bring their direct rendering infrastructure to its Linux drivers. Their hope is to broaden high-end graphics support in Linux. Check out the story here. "

113 comments

  1. Open source can't "Embrace and Extend" by Anonymous Coward · · Score: 0

    The whole point to "Embrace and Extend" is that you are adding proprietary extensions to an open specification. An open source program can not by definition "Embrace and Extend" since are the changes are in the open. I can get XF86 and compile it on any UNIX or OS/2, so this is not an issue.

    1. Re:Open source can't "Embrace and Extend" by MenTaLguY · · Score: 1

      The whole point to "Embrace and Extend" is that you are adding proprietary extensions to an open specification. An open source program can not by definition "Embrace and Extend" since are the changes are in the open. I can get XF86 and compile it on any UNIX or OS/2, so this is not an issue.

      Hrm; yes, I should have used quotes around "embrace and extend". It really isn't the most applicable term. I'm just concerned about a loss of portability of X applications that rely on the new extensions, in much the same manner as a lot of Linux programmers don't bother to make their code [easily] portable to other Unices. (although that is arguably a problem because other Unices are often rather broken in some areas :P)

      The anti-aliased text extension has the potential to be the worst culprit -- it introduces an entirely new API for drawing text, and supporting older X servers would mean writing all of your code that dealt with drawing text twice. (although hopefully you'd have abstracted it somewhat so that only meant one source module). Maybe we'll be lucky and that'll get handled by GTK and Qt. It may not really be that much of an issue after all.

      For the sake of argument, though, can you really compile XFree86 for any Unix? Can I, say, replace the vendor's X server with XFree86 on my HP-UX workstation here? What about other non-Intel non-Linux/*BSD systems?


      ---
      --

      DNA just wants to be free...
    2. Re:Open source can't "Embrace and Extend" by warmi · · Score: 1

      Sure , I know you can do this on Solaris 6 ( intel)

  2. 3dfx?? leader in 3d? hardly! by Anonymous Coward · · Score: 0

    just a publicity stunt to get attention from linux folks, who will later buy 3dfx's products. 3dfx aint shit i tellz ya. RIVA is the way.

    1. Re:3dfx?? leader in 3d? hardly! by mrmandrake · · Score: 1

      yeah. Nvidia TNT/TNT2/TNT2ultra is the great one. they're working on the NV10 which will be able to make textures 20x as small as TNT

  3. For applications? ...or just games? by MenTaLguY · · Score: 1

    In general with X, you do pay a fairly large price due to the network transparency issue; however XSHM and especially XDGA do alot to resolve this. Theoretically, DGA in full screen mode is as fast as windows, though I can't back this up with numbers.

    Well, I was really talking about applications in general, not just games. Most apps don't need or want to be beating on the framebuffer directly. XSHM can be applicable at times (imlib), but I don't really see how XDGA helps there...

    For applications, anyway, drawing on a bitmap or a framebuffer is not always a good substitute for using the (potentially) accellerated drawing primitives either, is it? I don't think X is that fundamentally broken.

    Also, just out of curiousity, how many non-XFree86 servers support XDGA?


    ---
    --

    DNA just wants to be free...
    1. Re:For applications? ...or just games? by riboflavin · · Score: 1

      In my post, I was referring mostly to games (3dfx and DRI both got me thinking about games). For applications, you are correct, beating on the framebuffer directly is usually a bad thing.

      However for an application, the speed at which X draws stuff isn't nearly as critical as it is for games/video players/etc, for whom beating on the fb directly can be an advantage. There's still room for improvement within the X protocol. For example being able to say "draw this widgit" would be much more effecient than saying "draw a line here, and a line here, and a pixel here..." However I think the slight loss of speed due to the client/server architecture is a small price to pay for network transparency.

      As to how many servers aside from XF86 support DGA, I'm not sure. My experience with Unix stops with Linux, and my experience with X stops with XF86. I hope that it becomes standard fairly soon, because it's very nice for writting programs in which framerate is important.

    2. Re:For applications? ...or just games? by Ben+Hutchings · · Score: 1

      DGA is really handy for running Windows games that use DirectDraw. Unfortunately this requires running them as root. If you aren't root, WINE's DirectDraw implementation can be really slow (hundreds of times slower in some cases).

  4. don't go bashing 3dfx by cruelworld · · Score: 1

    Bash the voodoo all you like, and bash their closed source libs if you want. However if it weren't for 3dfx and glide, there would be no Q3Test for linux, and Q3Arena would seriously lag the Windows/Mac release(if it were made at all).

    Maybe things have changed but I was under the impression that support for linux was a good thing?

    1. Re:don't go bashing 3dfx by Snack+Cake · · Score: 1

      Thank you. I couldn't agree more.

    2. Re:don't go bashing 3dfx by Anonymous Coward · · Score: 0

      it seems like everyone just has a serious grudge against 3dfx. even if they shouldn't have gone after individuals on the glide wrapper deal, that doesn't mean you should continually hold a grudge against them for that. sure, it's okay to say, "tnt2 has faster support under linux," because you wanna go with what's fast. go 3dfx. thank you for developing something for linux. you didn't have to spend any money doing it, but you are. thank you. -jm3

  5. DRI gives you both worlds by kalistra · · Score: 1

    I, like the other folks responding here, use the network transparency of X very heavily, just about every day. I would guess that your 5% number is very wrong, perhaps not on single user home systems, but certainly out in the corporate world where highly networked operating environments are the norm.

    Anyways, this doesn't address the 2D side of things, but the DRI deals with exactly the issue you raise on the 3D side. My (admittedly incomplete) understanding of it is that it will allow any code written to the very open and hardware independent API's of OpenGL and GLX to bypass most of the overhead that XWindows usually incurs, instead pipelining the requests directly to the 3D hardware that can support it.

    If anyone out there knows better than I, please correct any mistakes I may have made.

  6. You asked for it by VinceJH · · Score: 1

    When you say something like that, right away some guy is gonna respond, like he and the rest that use network tranparency are the norm. Im with you, id be suprised if network tranparency is even used 5% of the time.

    --
    I know I will be moderated down for this, but . . . Vincent
    1. Re:You asked for it by Pascal+Q.+Porcupine · · Score: 1

      Ever been in a university computer lab?
      ---
      "'Is not a quine' is not a quine" is a quine.

      --
      "'Is not a quine' is not a quine" is a quine.
      Quine "quine?
  7. Re:WM in the X server: dumb idea by Anonymous Coward · · Score: 0

    Microsoft tried something similar by tying a fair portion of the WindowManager into the executive space (kernel execution space) of Windows NT 4.0. This was anything but a good idea, and has caused a huge number of problems. Nevermind the fact that they also violated their own microkernel design. Check your MSDN documentation, if you can find it.

  8. Re:This is a Bad Thing by Iggy · · Score: 1

    I may be wrong on this but i have a feeling i read something about XFree4.0 that said that they were coming up with a binary format that would only need you to produce one binary for any architecture. Now this may be incorrect and i'm getting confused with something else, but have a look at the docs with XFree 3.9.15.

    Iggy

  9. Re:performance by Anonymous Coward · · Score: 0

    Unfortunately, as a practical manner right now, DGA requires your client to be set-uid root-- in other words, you are forced to give up all Unix security in order to use it.

    Hopefully this will change when the DRI becomes common; the DRI essentially lets non-root clients directly access the 3D hardware, and 2D should work the same way.

  10. Re:Hope 3dfx do the right thing. (WARNING: Flameba by Snack+Cake · · Score: 1

    I'm no 3Dfx zealot, but is there any 3D support whatsoever for the G400 in Linux? If there isn't (I don't think there is) then buying a G400 means buying a high-priced 2D board and wasting most of the hardware it contains, and a lot of your own money. Unless you are talking about using the G400 under windows, in which case, what does it have to do with this discussion?

  11. Point of 3D cards by Anonymous Coward · · Score: 0

    3D cards *do* offload the CPU but they are just one part of the "3D pipeline." The CPU is still responsible for feeding the 3D card with triangle data as fast as possible. The 3D card then renders these and puts textures onto them. While you may be happy with the performance (my PPro 200 is still ok but not great in q3test) you will see far greater performance in games with a well balanced system of fast CPU and fast 3D card. The BX6v2 is great board, got one myself.

  12. A win, lose situation by EEE · · Score: 1

    I'm really tired of all the bad mouthing of the voodoo 3. The voodoo 3 with a AMD K6 266 gave me great performance at a great price. I do have to sympathize with some people in that the linux drivers for 2d support kinda suck, but if 3dfx is really serious about selling the voodoo card chain to the linux consumer than they should focus on producing Xservers that have higher bit depth and high res to match the card's benchmarks.

  13. Re:Go 3dfx! by Anonymous Coward · · Score: 0

    > 3dfx has devoted themselves to supporting linux. Let's not hate them for it.

    If that's true, why can't I use my Voodoo cards in my Alpha, UltraSparc, or PowerPC systems running Linux?

  14. Re:3dfx thanks. DRI /GLX the route we got to take. by Anonymous Coward · · Score: 0

    > The only sucky thing is that there is NO HARDWARE ACCELERATION discussed in the future
    > plans with Xfree86.

    Only because no one's written it yet. The whole point of the DRI is to make hardware acceleration possible.

  15. I get more FPS from LINUX by Anonymous Coward · · Score: 0

    my v2, get 3 more fps under linux q3text 1.07:

    windows, all apps closed
    linux, netscape running and kde

    system: p2-333, 128 mb ram, 7200rpm ide hd, sound blaster 64 isa.

  16. Re:Wishful thinking. by Anonymous Coward · · Score: 0

    Try switching to a different console. The keystroke is ctrl-alt-[f1-f6]. Note that if you switch to a different console while running X, you can't get back to X. You get back to the console that is running X, but the console is controlling the screen. It would be nice if you could get X to refresh the video mode and its screen somehow, but I don't know of any way to do it...

    nathan

  17. mtrr registers by lubricated · · Score: 1

    look in /usr/src/linux/Documentation/mtrr.txt
    Set your mtrr registers it really helps me out alot on my TNT. The Voodoo3 with the mtrrs set is supposed to be the fastest thing under linux.

    Mike

    --
    It has been statistically shown that helmets increase the risk of head injury.
  18. Linux TNT OGL framerates(was: Re:Vodoo) by red_one · · Score: 1

    The ONLY reason I still use Windows is because of the far superior quality of the windows9x nVidia drivers.
    The linux drivers offer terrible framerates, with poor texturing performance, and no (?) AGP support.
    There is a long way to go before I switch to linux for my gaming (besides the lack of games).

  19. Re:DRI isn't hardware specific, right? by Anonymous Coward · · Score: 0

    Ya, that's the impression I got...without your comment, I would have thought a DRI was something like Glide.

  20. Re:Vendor Specific muddles? by Anonymous Coward · · Score: 0

    Um. Because lots more people use Linux. The game playing type. Companies (aside from maybe Red Hat and a few others...and they aren't any more) don't do things just to help because they feel nice. They're looking for new markets and monopolies...everyone wants to be M$ II.

  21. Re:Wishful thinking. by z4ce · · Score: 1

    Maybe you people should look into the kernel MagicKey... I have never used it but from what I hread it could maybe some how restore the keyboard to a sane-state.

  22. 3dfx suck badly!!! by Anonymous Coward · · Score: 0

    they suck period 1. inferior hardware 2. buggy as shit drivers for windows 3. late drivers for NT 4. always takes them longer to make opengl ICD thanthe fuken hardware. 5. buggy as hell hardware too, damn agp cards some times lockup 3dfx = shit

  23. I use X remotely ALL DAY LONG... by slothbait · · Score: 1

    My life would be unlivable without the network transparency of X. Whatever finally does displace X (possibly Berlin) absolutely *must* have network transparency.

    --Lenny

    1. Re:I use X remotely ALL DAY LONG... by Rational · · Score: 1

      "You don't eat, sleep or mow the lawn, you just use X all day long"...

      Sorry, couldn't resist, please moderate it down. :)



      --
      "Be nice, veer left, and never stop thinking" Iain Banks - Walking On Glass
  24. 3Dfx, and XFree86 Arch. DON'T BASH THEM! by Panaflex · · Score: 1

    Well, I personally would LOVE to use a VooDoo3. But, sucks for me, I run on ALPHA. I wrote 3Dfx about wanting to compile it on my Alpha. If they do that, then I'll go and do that.

    Hey, LETS NOT bash them. Sure, code is the BEST way to go about it. But they don't want to do that. No Big Deal. Once the linux market share goes to 5 percent, or 10 percent, and they see that nVidia, 3dlabs, and intel are all gaining market share on Linux quickly, then they might think about it.

    Read the Linux Advocacy pages. Drivers have a special place. The existance of Drivers is A Good Thing(TM). People always feel better then they get praise, and ohh by the ways; than being called driver hoes.

    In fact, I wrote nVidia and 3Dfx about my experience getting my card(s) working. I settled on nVidia. (I still don't have glx working properly however.) I'm going to buy another video card, and it better have alpha support. (Hrumph!)

    Roger

    --
    I said no... but I missed and it came out yes.
  25. 3D support for Linux by Anonymous Coward · · Score: 0

    I bought a Voodoo3 seeing that Linux supposedly had support but like someone up top said, it's iffy at best. I couldn't even get the Glide test script to even recognize I HAD a Voodoo3 in there even after installing all the things from glide.xxedgexx.com. I don't think I'm that much of a newbie but this stuff is ridiculous. I gave up on the whole thing and just stuck my Matrox Millenium (yes, the OLD v1 one ;-) back in and took the crappy Voodoo3 back to the store for a refund. The X server seemed to work fine but it was odd that my machine actually seemed to be running slower (bogomips were even lower!) with the V3 in! I guess this system is just getting old but it seems fast enough for my Linux needs.. PPro-150, SuperMicro P6SNE, etc. Anyway, I gave up and found a decent deal on a Voodoo2 and that works fine under Win98 (well, other than Win98 crashing but that was happening before I installed the card. Time to go back to Win95 OSR2 I guess). Still need to try it under Linux though but hopefully the older non-bleeding edge stuff should be better supported. ;-)

    1. Re:3D support for Linux by Synic · · Score: 1

      Voodoo3 on a PPro 150? Jeez! You'd be better off buying a new motherboard and processor! Graphic accelerators are limited performance wise by your CPU, so don't expect miracles.

      Go do yourself a favor and save up for an Athlon and Slot-A motherboard. =)

  26. Re:Do we _have_ to use X for everything? by Anonymous Coward · · Score: 0

    X is not necessary, but there's some functionality already there (or being developed for Xfree86) that I don't know if exists for console mode apps. Remember that these drivers do not target only games, but also any app that uses OpenGL. For example, there's GLX, if you want a remote app to be accelerated in your hardware. Also, multiple apps using the same rendering hardware (I think that would be quite cumbersome to handle in console mode, and I think this is what you were talking about in your post about the kernel taking care of it). There's already 3D support in console for 3dfx cards (I think Quake x can run accelerated under SVGALib + Glide, I'm not sure on this). There's also the GGI project, but it's been ages since I last read about it. But X provides some other things than "full-screen accelerated games".

  27. Re:WM in the X server: dumb idea by warmi · · Score: 1

    They did this to speed up GUI in 4.0 ( 3.5 sucked ) and they succeded ...

    If you have problem with graphics subsystem on the server - make sure to run VGA and everything should be OK. VGA driver is rock stable.

  28. NVidia's Already Done It by ewhac · · Score: 2

    For those who didn't know, nVidia has already released an OS-neutral driver suite for the RIVA 128, TNT, and TNT2 series of chips. Fully compilable source for the entire suite is provided under a BSD-ish license. (The source isn't very educational, however, as it's been run through 'cpp'.) Sample driver implementations and example code for Linux and Windoze-NT also accompany the distribution.

    The suite is designed to function as low-level support for all rendering and display functions. These functions are exposed in an object-oriented-like fashion at a hardware level. Whatever the hardware doesn't support directly is thunked over to software. Thus, the public API for the NVidia chips is the hardware channels.

    This has been out for several weeks now, but every time I've submitted it to Slashdot, it hasn't been approved. Oh, well...

    Schwab

    --
    Editor, A1-AAA AmeriCaptions
  29. Re:Sounds good by warmi · · Score: 1

    If slowing down X network access would mean speed up of local execution I am all for it.

    (In fact one can easily use VNC and skip X networking altogether )

  30. Re:Vendor Specific muddles? by bugg · · Score: 1

    Perhaps this is OT, but exactly why do so many companies see a need to support Linux? If their goal is to promote up-and-coming OSes, perhaps they should release source and let the hackers out their DIY or say they are also releasing FreeBSD. Linux isn't the only free-software up-and-coming OS on the market, you know.
    But if i understand properly they are talking about improving X. That'll affect _ALL_ UNIXes.
    I've used both FreeBSD and Linux, and i have my own personal opinion on which one is better. I don't want to start any religious wars, as to each his own, but heres a hint (my favorite isn't the second one).
    I think that EVERYONE out there should try both. Only fair.

    --
    -bugg
  31. Re:This is a Bad Thing by warmi · · Score: 1

    Nope. Alpha or PPC will still need it's own binary.

  32. Re:Vendor Specific muddles? by warmi · · Score: 1

    When you mention your personal opinion regarding OS do you mean server or workstation usage type?

  33. Which one is REAL? by Anonymous Coward · · Score: 0

    Okay, now I have people telling me that DRI is going to solve all of our awful suid X server problems. Excuse me while i put that on the shelf next to fbdev and KGI/GGI, which both seem to promise the same thing. Someone *please* explain to me that this is not a clash that will be an order of magnitude worse than when debian potato switched to glibc6.1 . Please?

  34. PPro by Anonymous Coward · · Score: 0

    What's wrong with a PPro-150? Outperforms a Pentium 233 as far as I've seen. As for why I went with the Voodoo2 instead.. $79 was cheaper than $700+ to buy a new system. My PPro-150 is MORE than fast enough for anything I've thrown at it under Linux. As for Graphic accelerators.. I thought the entire point of a damned 3D card was to offload the need for a high end processor and let the 3D card's hardware handle the 3D intensive stuff? Ah well, someday I may buy a new system but I haven't found ample justification to spend $700 to get something like a Celeron 433 with 128 megs of ram, Abit BX6v2 motherboard, etc. I guess my problem is I don't want to gut this machine I have currently so I need to buy everything (except a monitor) new. :-/ Otherwise I have a brand new 10 gig UDMA drive in it I could have used.. but the 3c509 and the SB16 ISA cards are both out of date. I'd rather get rid of ISA altogether.

    1. Re:PPro by Archangel_ · · Score: 1
      "I thought the entire point of a damned 3D card was to offload the need for a high end processor and let the 3D card's hardware handle the 3D intensive stuff?"

      This will be true when nVidia releases their next chipset code named NV10, which has full hardware transform and lighting acceleration...This is really going to piss Intel off...

      "Ah well, someday I may buy a new system but I haven't found ample justification to spend $700 to get something like a Celeron 433 with 128 megs of ram, Abit BX6v2 motherboard, etc."

      You can upgrade your system for far less; approximately $450 now that's assuming you need a new case (AT -> ATX) plus 128 megs rams. Now you dont have to take my word it, you can go to www.computernerd.com for MBoard/CPU/Case bundle and to www.mwave.com for memory and see for your self. You can also checkout www.killerapp.com for computer hardware prices.

      Now me personally I plan to purchase Abit's new dual slot 370 motherboard with two 366Mhz celerons guaranteed to overclock to 550Mhz for $412....

      --
      "Gravity must be scholastic occult quality or the effect of a miracle."
    2. Re:PPro by Snack+Cake · · Score: 1

      I think that saying the point of a 3D accelerator is to "offload the need for a high end processor" is a bit of a mis-statement. I don't think there is a PC on the market yet that can even play Quake 1 in OpenGL mode at 640x480 at more than 1 fps if software rendering is used. The point of a 3D accelerator is to get speed and quality that would be entirely impossible without one, not to ease the burden on your CPU, or to save you the trouble of getting a new one.

  35. Re:Go 3dfx! by Anonymous Coward · · Score: 0

    yeah, 12 months for an Xfree server, yep thanks heaps loosers

  36. Re:Good News by Anonymous Coward · · Score: 0

    yeah, how long does it take hardware engineers to make a 3d card? 3months, how long does it take the software engineers to write drivers for it? 12months. what a fucked up company

  37. Re:Wishful thinking. by Axe · · Score: 1

    As if I did not try. It would be easy then...
    No, the damn thing freezes dead solid sometimes.

    BTW, you are wrong about not getting back to X,
    right now: ctrl-alt-f2 - and I logged in as root.
    ctrl-alt-f7 - I am back in X. It worked.

    Boy, isn't Netscape under Linux ugly...

    --
    <^>_<(ô ô)>_<^>
  38. not sure if this was mentioned yet... by starrcake · · Score: 1

    http://glide.xxedgexx.com/

  39. Re:Hope 3dfx do the right thing. (WARNING: Flameba by VinceJH · · Score: 1

    I think so. Try the glx from CVS.

    --
    I know I will be moderated down for this, but . . . Vincent
  40. Re:Developers-Retooling X by Des+Herriott · · Score: 1
    First, retool the chain from application to server. Instead of ALWAYS using sockets, write a new path on the libX11.so library so that commands are fifo'd using shared memory to the X server. Get rid of the X protocol over local connections(which require quite a bit of time decoding and encoding... think PPP), and use something more like System.map. Build the protocol over a shared memory fifo buffer. This _MUST_ be backwards compatable. Same library. Just a new life for old apps.

    This is a pretty good idea. In fact, it's already been done by someone else - IBM. The AIX X server uses a shared memory transport for all X requests if client & server are on the same machine. This confused me for a while - where's the XShm extension on AIX, I wondered? Ah, it doesn't need, since everything's shared anyway.

    I don't understand what you mean by getting rid of the X protocol though - you mean giving clients direct access to the hardware? Sun did something like this with their SUN_DGA extension (which is not the same as the XFree86 extension).

    Build enlightenment/wmaker/fvwm/etc.. as a library. Allow the wm to be linked into the X server(I know, but but it's a good thing). This would lower the context switches a good bit. because you'd get rid of the X/WM/CLIENT clusterfsck that can often happen when you have an app running and you MOVE THE MOUSE (Ohh My God). Besides, if you want to switch WM's - we use the libdl.so to kill the hooks, blow out the old wm lib, and relink the new lib

    I can sort of see what you're getting at here, but (a) it would be a truly monumental task, and (b) I don't think it would buy you much.

    Another interresting notion, would be to allow X to load toolkits (server side) like KDE/GNOME/Motif/Xt into the X server...

    What you're describing is pretty much what the Berlin people want to do. Take a look at their website - there's some very interesting and thoughtful design there.

    You have some good ideas, but IMHO, you should look at contributing to Berlin, rather than reworking X. Especially since a lot of your ideas are already there :-)

  41. ATI by Larry+L · · Score: 1

    actually ati cards under linux have been known to run faster than under windoze because ati wrote crappy drivers.

  42. Supports my HP workstation? by MenTaLguY · · Score: 1

    In other words, it doesn't. You mention Solaris -- does it support Solaris/SPARC? What about AIX? What about Digital Unix/Alpha? What about IRIX/MIPS? Specifically what non-Intel architectures _are_ supported?

    The Unix world is not all Intel Unix clones. Far from it. Get some perspective.

    ---

    --

    DNA just wants to be free...
  43. If the 3d hardware is in place... by Pengo · · Score: 1


    Without the game market, Linux will not make it big on the desktop.. IMHO. Sad fact.

  44. Will it do any good? by angelo · · Score: 1

    I mean, good for them writing a dri driver. I guess we could use something like this. But my problem is they only released it as DRI because you don't need to release source under such a system, since it's a pluggable binary/library.

    It's funny, since they should work about keeping the dies for their chips a secret, and not the software that interfaces with it.

    I'll keep my nVidia (even though it crashes blender) and run with that. If I can keep the nVidia drivers from crashing, I'd use it to full potential. I'll have to wait for X11R4

    --
    Lowmag.net
    1. Re:Will it do any good? by angelo · · Score: 1

      Duh, preview before posting... I mean XFree86 4

      --
      Lowmag.net
    2. Re:Will it do any good? by Anonymous Coward · · Score: 0

      h.t.t.p.!!!! :)

    3. Re:Will it do any good? by angelo · · Score: 1

      Yeah, I know, I know. At least THAT's fixed. It would be nice if the preview were forced once sometimes.

      --
      Lowmag.net
  45. My RIVA TNT *Rocks* on linux. by Pengo · · Score: 1

    Just as an TNT X server just rules, it seems to run much quicker than any other X server I have used... just as a 2D vidio card in general, the TNT is just a fantastic card... cheep too now.

    :) (Not to mention has good game perf too...)

    1. Re:My RIVA TNT *Rocks* on linux. by warmi · · Score: 1

      What chipset is it based on ?

    2. Re:My RIVA TNT *Rocks* on linux. by great+om · · Score: 1

      RIva TNT is the chipset

      --
      ------- Oh damn.... the Sigfile escaped... -Great OM
  46. DRI isn't hardware specific, right? by Emil+Brink · · Score: 1

    I don't like the way this press release talks about developers writing "for 3dfx hardware". The DRI is for use with OpenGL and other hardware-agnostic APIs, so most developers won't really care what hardware is in the box. But of course, stating it that way lessens the number of times you can include "3dfx" in your message.

    --
    main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
  47. Great by Anonymous Coward · · Score: 0

    Well, this is good news, if there will be good supported 3dfx drivers from company's, there will also be a better way for game manufacteres to support those drivers and hence, more games and more other utilities get for linux.

  48. Useless by Anonymous Coward · · Score: 0

    So long as 3dfx only has binary-only support, it's quite useless. The current cards will presumably only work with old versions of xfree86. We won't be able to hack on the drivers to make them fast. It's really quite pointless...

  49. Whatever... by Anonymous Coward · · Score: 0

    Between the Riva TNT2 and the Matrox G400, I don't think 3dfx has what it to compete. Besides, they've been such assholes about the glide-compatable libraries that people have put out that I really don't want to do business with them again anyway.

  50. version problem by Anonymous Coward · · Score: 0

    Win98 has DirectX/Direct3d, etc. X connections go through the slow-ass-for-3d X protocol. X will continue to be much slower than Windows so long as this is the case. Fortunately, this will no longer be the case with XFree86 4.0, which ships with DRI (direct rendering infrastructure).

    1. Re:version problem by warmi · · Score: 1

      That's not it. At least not in my case. I am not talking about games - just simple GUI operations ( moving windows, resizing ) - stuff like that is slower.

  51. FYI: Red Comments by Ramses0 · · Score: 1

    It is apparently some bonus feature of their news-interface that highlights the words you searched for. It looks like somebody was searching for "Red Hat" and then mailed this link to Slash.

    You can verify this by clicking the: "Jump to first matched term" link at the -very- beginning of the article.

    FYI

  52. Vodoo by warmi · · Score: 1

    I have Vodoo 3 and sadly, under Linux it is visibly slower than Windows running on the same box. In fact, on the other box I have G200 and it is slower too.
    Have anyone ever encountered graphics card that run faster under Linux than under Windows95 ?
    Is this driver issue or simply X is slower than Win GUI subsystem ?

    1. Re:Vodoo by davie · · Score: 2

      The problem is that your X server isn't using your graphics chipset's hardware acceleration capabilities. XFree86 4.0 will address some of this, and I'm sure the dot releases following will bring some pretty good performance gains. I'd settle for my TNT delivering 90% of the performance I get with the same card in one of my other machines that runs Win 95.

      I was getting half-way decent on Q2 DM on that Winnders box, but I got sick of the constant crashes (not to mention the fact that I wasn't getting any work done). With hw accel. on Linux, I could go back to being a total slacker and rule my favorite DM server!

      --
      slashdot broke my sig
    2. Re:Vodoo by Anonymous Coward · · Score: 0

      I find the Windows interface really bogs down the fast video subsystem. X + my personal favorite window manager (ctwm) is significantly more responsive than either WIndows 98 or Windows NT on the same machine. So even if their drivers are better, Linux feels faster. FOr me that is good enough.

    3. Re:Vodoo by Anonymous Coward · · Score: 0

      Windows implements much of the GUI within the kernel, which allows for greater performance and less overhead in windowing tasks. This is also one of the reasons windows is so unstable, because any GUI failure is in effect a kernel failure. X windows is implemented at the application layer which eliminates the stability problem but causes increased overhead for GUI functions. There are methods to eliminate this overhead, e.g. the use of an exokernel to allow direct access to hardware, however I am not aware of any such mechanisms present in the Linux kernel.

    4. Re:Vodoo by N1KO · · Score: 1

      My 1 meg trident video card runs as crappy on linux/X as on Windows.

  53. Hey, back off..theyre using PROPAGANDA. (grin) by Bowie+J.+Poag · · Score: 1

    Got e-mail from a guy at 3DFx like a week or so ago, asking my permission to use PROPAGANDA seamless tiles in the product demos theyre giving. Unfortunately, I wont be at the expo to see them in action, but if I were you, i'd look forward to such a demo. :)

    Bowie
    PROPAGANDA
    Bowie J. Poag

    --
    Bowie J. Poag

  54. Feh! by abamfici · · Score: 1


    3dfx needs to be fixing my Voodoo2 before they go out and do all this 2d/3d card stuff. Come on Daryll, I know you read slashdot, quit tooling with the demo for that graphics convention!

    Anyone have clues as to why "Red Hat" was in red?

    ~Kevin
    :)

  55. 3DFX Old news? by Anonymous Coward · · Score: 0

    I thought TNT2 was a much better chipset according to the review Tom did.
    What could we use this for that TNT2 can't replace?

  56. Do we _have_ to use X for everything? by MenTaLguY · · Score: 2

    Well, this is unquestionably a Good Thing(tm), but it really would be nice if it were possible to do 3d graphics decently _without_ X, too. (none of this beating directly on the hardware in each individual app stuff)

    While you unquestionably need some central facility to arbitrate access to and abstract the graphics hardware (which is why svgalib doesn't realy cut it -- each app banging on the hardware directly is NOT a modern or a safe way of operating), it'd be nice if you didn't have to pay for the memory overhead of X if you didn't really need it (and it is considerable). Or the startup time -- not all of us keep an X server running continuously.

    It'd be nice to see the kernel doing its job with arbitrating access to hardware, although that usually means an in-kernel abstraction layer too, which we really don't want. Partly because it can be a severe cause of bloat, and partly because there's no real obvious way to abstract most graphics stuff without breaking the standard Unix 'everything-is-a-file' metaphor. Except maybe for abstracting really basic stuff, like the framebuffer, which is what fbcon does.

    We do still need to arbitrate access to accelerated graphics though, especially in light of the existence of poorly-designed hardware where you can inadvertantly (or deliberately) lock the bus and other fun things by poking accel registers. Maybe KGI will mature someday; the design seems to manage that pretty well without foisting an ungainly abstraction layer on the kernel.

    *sigh*

    Or maybe I'm just blowing smoke. I dunno. I'm not faulting the 3dfx folks. There are a lot of times you want or need 3d in X, and DRI is the cleanest way to do that. It's also the only emerging "standard" way we have of doing this 3d stuff cleanly right now, in any environment.


    ---
    --

    DNA just wants to be free...
    1. Re:Do we _have_ to use X for everything? by MenTaLguY · · Score: 1

      X is not necessary, but there's some functionality already there (or being developed for Xfree86) that I don't know if exists for console mode apps.

      Yes, that's exactly the thrust of my first comment -- some of this stuff SHOULD be possible independently of X.

      For example, there's GLX, if you want a remote app to be accelerated in your hardware.

      GLX, in particular, probably is one of those things that belongs in X. I'm not desparate for network transparent console video. However, I would like to be able to have otherwise well-rounded video support outside of X. For a lot of specialized applications, X is just too big, but there aren't any good alternatives for accelerated graphics right now. (no, writing your own drivers in userspace a la svgalib is not a good alternative)

      Also, multiple apps using the same rendering hardware .... There's already 3D support in console for 3dfx cards (I think Quake x can run accelerated under SVGALib + Glide, I'm not sure on this).

      This is exactly the problem. You can't reliably share the graphics hardware right now without going through X. That needs to change. As far as SVGALib + Glide, that was precisely what I was referring to when I said "each app banging on the hardware directly is NOT a modern or a safe way of operating." (granted, it's not as bad if you have /dev/3dfx set up, but that's _hardly_ a generalist approach)

      There's also the GGI project, but it's been ages since I last read about it.

      KGI is a GGI subproject.

      But X provides some other things than "full-screen accelerated games".

      Sure, but sometimes people don't NEED those other things. Also keep in mind that there are some application types besides games that require fullscreen accelerated graphics.


      ---
      --

      DNA just wants to be free...
  57. 3dfx. Feh. by tietokone-olmi · · Score: 1

    Wasn't it 3dfx that was so jealous about their code and APIs (remember the GLIDE wrapper lawsuits)? I wouldn't be surprised if their "contribution" would be closed-source/with a really restrictive license.

  58. Developers-Retooling X by Panaflex · · Score: 1

    Been looking at XFree86 4 code.. I want to retool it. I want to say YEAH!! to XFree86 on a good path. BUT...

    I've looked at the new driver module API for XFree86, and I am going to retool X into something different. X will still suffer from a few problems, well known. I have an answer to some of these.

    First, retool the chain from application to server. Instead of ALWAYS using sockets, write a new path on the libX11.so library so that commands are fifo'd using shared memory to the X server. Get rid of the X protocol over local connections(which require quite a bit of time decoding and encoding... think PPP), and use something more like System.map. Build the protocol over a shared memory fifo buffer. This _MUST_ be backwards compatable. Same library. Just a new life for old apps.

    On the X server side - take all the networking code and build a protocol switch on it. (Thus leaving complete remote compatability.) On the other switch, allow a shared memory FIFO.

    This change alone would reduce the context switched by about 1/3rd (best case) to 1/8th (worse case)

    Build enlightenment/wmaker/fvwm/etc.. as a library. Allow the wm to be linked into the X server(I know, but but it's a good thing). This would lower the context switches a good bit. because you'd get rid of the X/WM/CLIENT clusterfsck that can often happen when you have an app running and you MOVE THE MOUSE (Ohh My God). Besides, if you want to switch WM's - we use the libdl.so to kill the hooks, blow out the old wm lib, and relink the new lib.

    On the XServer side, some other good things could be done. One big thing is the rectangle management code under X __!!!SUCKS!!__ performance wise. (Read the X source code, it's in there). Basically, X takes all visible windows (and portions thereof) and builds a rectangle list. This would seem to be A Good Thing, but it actually sucks. Instead of some good rectangle management code, everytime you move a window - X MUST build this damn rectangle map. Oftentimes (with shapes turned on) this can add up to a hundred thousand rectangles. (Add some debug code in there - it's horrendous).
    Don't know what to do about this (It's pretty deeply imbedded into X). Ideas? I think some dirty-rectangle backend would work wonders. On the Amiga, the sytem was alot better. Rather than try and big-brother applications, it simply gave the drawing library a list of rectangles. Visibles and buffers to non-visibles (If it was buffered at all) The drawing lib drew into visibles, and backbuffers. If there was no backbuffer - too bad. X is simular to this, but the rectangles are maimed. Also, there is a gigantic spin-lock on the DDX. This is wrong!!!

    Another interresting notion, would be to allow X to load toolkits (server side) like KDE/GNOME/Motif/Xt into the X server. This keeps client fatness down substantially. The only problem is that these toolkits were't designed from a server architecture. They were designed to be an upside-down christmas tree into the X server. A way around this may be run a toolkit as a thread for each client. On the client side, you would still build the clients with the libgnome, but the lib would have an optional direct-interface into the X server toolkit. (Again, a protocol "switch")

    With a multithreaded X architecture, this would ROCK! Seperate the DDX from the DIX layer threads. Allow the DDX to accept drawing lists, and the DIX to yack at clients. This would allow you to cut your timeslices mo better for the DDX layer. Also, the DDX could operate independantly and simply be blasting pixels from a FIFO command buffer, and operate the DGA semaphores.

    Anyhow, I'm soliciting some help in retooling. I think we're dumb to throw away X, but at the same time - this RELUCTANCE to mess with X is dumb. X needs a REAL direct rendering interface. Not just for special clients, but the whole architecture The design of X is monolithic and completly unoptimized for todays archetecture (Think about SMP?? Look at how bad MESA performs on SMP. Thnk about the X server doesn't help at ALL). With some COMMON sense, we could pry the network-only fingers of code from the DDX and DIX and build optimized pathways.

    All this, while still using the XFree86 driver modules. That's right. We won't have to touch and drivers. (That was always the hard part). All we do is build a new client->server path.

    davenrs@cyberonic.com
    davenrs@mail.excite.com

    Rog

    --
    I said no... but I missed and it came out yes.
  59. Linux drivers for V3500 TV features? by Anonymous Coward · · Score: 0

    Under 98 this thing can act like a VCR. What's the chance that 3DFX will develop Linux drivers that do the same?????

  60. Joking?! by Anonymous Coward · · Score: 0

    Are you kidding? being able to see graphical apps on a remote machine is the wave of the future. Winnt has attempted to catch up to this incredible design in X with terminal services for nt4 and 5. If X is without network connectivity what good is it? linux/unix's beauty is that i can be anywhere and access my machine as if i was at the console. i'm looking forward to 3d apps being useful via the internet. I realize that bandwidth contraints would not allow this for quite some time, but just imagine it.

  61. Which 3d card is best? by Anonymous Coward · · Score: 0

    I have been looking for a 3d card that works in Linux, and don't know what to get. The G400, TNT/TNT2 and 3dfx all work in Linux right? So which one is the best? Anyone with experience with them? I want reasons why also, not just "this card is better than that one blah, blah , blah." Thanks. Oh yeah, how about frame rates in games and such. Foxer

  62. Sounds good by Anonymous Coward · · Score: 0

    - as long as you don't slow down or remove the ability to do X remotely (so you've got 2 communications pipes - FIFO through shared memory for local clients, good ol' sockets for the remote clients) and as long as you don't break existing apps, more power to you! DG

  63. 3dfx thanks. DRI /GLX the route we got to take. by Anonymous Coward · · Score: 0

    Thanks 3dfx. I was waiting and waiting for DRI to get somewhere... Its annoying trying to write Mesa code only to run only limited support. At one point it seemed the only hardware was with sgi. 3dfx changed all that. The route for linux 3D is going to be GLX. I was weary of DRI because of the sgi/prec insight backing.. sounded as if they could turn around and go propriatary. but when it was later announced as an open solution it was the best bet. 3dfx did the RIGHT THING by supporting DRI (which included directly GLX) in their cards and are going to dominate the linux graphics card market if they don't do already. 3dfx has a good linux developer connection. go and try writing apps in linux. they are very vocal with their support. although binaries would REALLY BE A BAD SIGNAL. The NEXT STEP is for Xfree86 to release 4. with the DRI api and with a few cards supporting it. The only sucky thing is that there is NO HARDWARE ACCELERATION discussed in the future plans with Xfree86.

  64. Yes, Linux G400 3D support exists by Ribbit · · Score: 1

    The GLX project supports the G200, G400, and the nVidia chips. The driver isn't exactly ready for the naive end user, but it runs the Quake games and the OpenGL hacks in the XScreensaver package, so it's quite functional. It's a bit slow, but it's getting faster all the time, and Matrox have recently made some WARP code available, which will allow use of the geometry engine.

  65. But try Q3Test on it... by longspur · · Score: 1

    I've used a TNT and a V3 in the same box, and they both seem to be pretty quick in 2d. Q3Test is really only playable with the V3, though. I'm hoping that XFree4.0, and possibly this 3dfx DRI will change the Free Un*x 3d landscape...

    --
    keep acting shocked and move slowly towards the cake.
    1. Re:But try Q3Test on it... by LinuxGeek · · Score: 1

      The first Nvidia release for Xfree86 is a pipe/stream based solution. This will change when the DRI solution is integrated into XFree86 4.0. What it means to be stream based is that I can run an opengl app on a remote system and display it on my local Linux box with hardware acceleration. But by sending everything through a named pipe to the X server, you don't get complete acceleration.

      What I have seen of the DRI implementations seem very speed competitive with windows systems. I can't remember specific numbers but seems like it was within about 10% on some of the unstable stuff at Linux Expo '99 ( they didn't have a mouse on the system 'cause if you moved the window, X would crash). It got much better after that.

      --

      Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
  66. Re:WM in the X server: dumb idea by Panaflex · · Score: 1

    It can be done. Essentially, the wm runs as a thread. IT STILL must go through the DIX layer, thus the wm isn't getting anything more special than it currently is, it just incurcs a much lower context switch being a thread. An added bonus will be that the X server can monitor the WM thread and kill/restart it when and if it fails - automatically.

    --
    I said no... but I missed and it came out yes.
  67. OS's that XFree86 supports by Anonymous Coward · · Score: 0

    From http://www.xfree86.org/3.3.4/index.html FreeBSD ISC Linux LynxOS NetBSD OpenBSD OS/2 SCO Solaris various SVR4.x Unix systems

  68. How many fps? by Anonymous Coward · · Score: 0

    How many fps do you get on q3testdemo1 and q3testdemo1 in v1.07? I have a Celeron 300@450 and Voodoo2 and get between 30-40.

  69. Vendor Specific muddles? by Laxitive · · Score: 1

    I see a recent trend with companies "coming out of the closet" and announcing Linux support, but failing to fully embrace the whole philosophy. From this article, what I can gather is that now people will be able to program fast graphics for 3dfx cards. unless this DRI is also implemented by other companies with competing video cards.. this announcement is useless. Is the DRI even an open standard? Will 3dfx sue anyone else that tries to implement the same interface in Linux, like the whole smelly affair with glide? Is 3dfx going to release the source, or keep it binary only? All these questions lead to muddles.

    If you really want to get excited about graphics on Linux.. take a look at GGI and Mesa.. both seem to be progressing extremely well, and try to provide full cross platform support for all types of cards. For some reason, this doesnt excite me that much.... (maybe it's because I just got my G400.. and it rocks my world)..

    -Laxative

    1. Re:Vendor Specific muddles? by Todd+Knarr · · Score: 1

      3dfx doesn't own DRI. DRI is the interface between XFree86, the OpenGL modules and the hardware driver that allows near-direct access to the hardware without breaking the X server in the process. 3dfx is just making a hardware driver that will follow the DRI spec so that XFree86 can use it. The XFree86 folks "own" the DRI spec.

      The whole announcement doesn't excite me much. nVidia already has half-decent open-source drivers, will be ready with DRI ones when XFree86 v4 comes out and the TNT2 chips match the latest 3dfx hardware and will keep improving while 3dfx seems to have max'd out. 3dfx has annoyed me greatly with their Glide stunts. What reason do I have to buy their hardware?

  70. To be brutally honest... by Anonymous Coward · · Score: 0

    This seems like another stab by 3Dfx to get some attention. I've done quite a bit of development with their Glide library (version 2, since they have not YET gotten version 3 out for Linux), and to be quite honest I have not been happy with with 3Dfx. Their documentation is not always thorough, and their linux support, although important, has not been as serious as I would like. I recently purchased a TNT2 card over a Voodoo 3 to replace my aging Voodoo 2, and I won't ever go back. The pure speed of the TNT2 combined with the available source has been enough for me to stick with Nvidia. 3Dfx can continue foistering 16 bit color (No, I don't want to hear about the 22 bit color combine stuff-you program for 16 under that chipset, and this 22 bit color combine doesn't gain you much to speak of. Anything else is 3Dfx trying to deflect the issue for their shareholders.), on us all it wants, but I want to use a quality chipset. My Voodoo 2 is currently sitting in my testbed machine so I can still support that chipset. I just hope Nvidia gets 32 bit GLX support finished for the TNT2 soon. Usually logged in as Watcher, but for some odd reason I can't remember my password. Bother!

  71. performance by MenTaLguY · · Score: 1

    > Is this driver issue or simply X is slower than
    > Win GUI subsystem ?

    Well, in general with X you do pay a fairly large price for marshalling/demarshalling commands for relatively low-level drawing primitives, even for local stuff. Yes, there's the SHM extension, but that's only if you want/need to implement your own drawing primitives and scribble on the bitmap. And you lose network transparency if you rely on that.

    The Win32 GDI (as far as I know) is basically a matter of local method invocation, with possible marshalling/demarshalling over a network connection going on behind the scenes in cases like Windows Terminal Server, but otherwise it's all local.
    ---

    --

    DNA just wants to be free...
    1. Re:performance by Forbin · · Score: 1

      I use X over a network all the time. Eventhough I typically use the command line for most things, it is nice to be able to run a GUI app and have it display locally. This is one feature I would NOT want to see go away.

    2. Re:performance by warmi · · Score: 1

      Hell, I don't really give a damn about network transparency.
      If network transparency is slowing X so much as you imply then , heck, this was terrible design decision to include feature that is used 5 % of the time and slows the whole thing even if you don't use it.
      Come on, it is nice to brag about X networking abilities but truly, how many people use it as compared to running X locally.

    3. Re:performance by riboflavin · · Score: 1

      In general with X, you do pay a fairly large price due to the network transparency issue; however XSHM and especially XDGA do alot to resolve this. Theoretically, DGA in full screen mode is as fast as windows, though I can't back this up with numbers.

      As far as the difficulty of using these extentions is concerned, you make a valid point. However, just as most people don't use Xlib to make X applications, most people don't use XDGA to write games. Instead, they use libraries such as SDL (Simple DirectMedia Layer) which abstracts XDGA (and many other platforms).

    4. Re:performance by Pascal+Q.+Porcupine · · Score: 2

      I use it all the time at work. My main project involves coding something on an SGI Octane using a library which we only have licensed for the Octane. My workstation is an O2. So, I remotely display the program from the Octane onto the O2, and it works great. Of course, it runs much fasbter when/if I runt it locally on the Octane, but since the Octane sits on my manager's desk and not mine, that's a bit difficult.

      Ennyhoo. The reason the TNT driver currently only does GLX is because GLX is just so much simpler to implement and keep synchronized. That's what the DRI is all about. And anyway, q3test runs adequately on my TNT even through the GLX-only driver, as long as I turn off lightmaps (admittedly, GLX really sucks when it comes to texture thrashing, and it doesn't help that the GLX driver has no AGP support yet).
      ---
      "'Is not a quine' is not a quine" is a quine.

      --
      "'Is not a quine' is not a quine" is a quine.
      Quine "quine?
  72. 3DFX is "high end" ??? by riddley · · Score: 1

    I always thought that they made junky proprietary game cards...

    1. Re:3DFX is "high end" ??? by Gleef · · Score: 2

      3Dfx makes junky proprietary graphics cards that until recently were faster than everybody else's junky proprietary graphics cards. Now nVidia's Riva TNT2 is faster, and has free (BSD license, but hard to read source) drivers, there's little place left for 3Dfx in my world.

      ----

      --

      ----
      Open mind, insert foot.
  73. WM in the X server: dumb idea by Maciej+Stachowiak · · Score: 1

    Build enlightenment/wmaker/fvwm/etc.. as a library. Allow the wm to be linked into the X server(I know, but but it's a good thing). This
    would lower the context switches a good bit. because you'd get rid of the X/WM/CLIENT clusterfsck that can often happen when you have
    an app running and you MOVE THE MOUSE (Ohh My God). Besides, if you want to switch WM's - we use the libdl.so to kill the hooks, blow out the old wm lib, and relink the new lib.

    Your other suggestions sound good, but this is a stupid idea. Right now if your window manager crashes, or hangs, or even worse hangs with the X server grabbed, you can kill and restart it and the X server keeps chugging. If it were dyn-loaded, a WM failure would mean your whole
    X server is toast. Plus WM memory corruption
    would mean scribbling all over server memory: bad!

    But the real reason it sucks is that it is totally optimizing the wrong thing. Show me _any_ app where the performance bottleneck is manipulation of top-level windows (this being the only time the window manager gets involved) and I will show you a really poorly designed app. Most times the WM is doing anything it is user interaction with window decorations, or a new app coming up, and the context switches are not the bottleneck there.

  74. No Q3test? by Anonymous Coward · · Score: 0

    What do you mean there'd be no q3test for Linux? I run q3test on my Celeron 500 + Viper 770 TNT2 Ultra and it flys! 1024x768 OPenGL with full texturing and lighting effects on. I grabbed the X server and the glx.so module from nVidia's ftp, installed, fiddled around with some symlinks, and I have TNT2 acceleration.

  75. Good News by Snack+Cake · · Score: 1

    3Dfx are being stupid with the Glide emulation (wrapper) thing. However, this announcement is still good news for those of who _own_ a Banshee or Voodoo3. I bought a banshee when I built my Linux box, because I saw it had drivers, and the NVidia drivers are "development only", and not really fast enough for games. (At least with a TNT. With a TNT2, it is probably playable.)
    Now that I have a banshee, I'm finding out that the Banshee drivers are pretty iffy and crash-prone. I can pull my TNT out of my other box, and use it in Linux, but then I get horrid 3D performance.
    I'm hoping that this announcement means my banshee will have good 2D and 3D support sometime in the near future.

  76. Hope 3dfx do the right thing. (WARNING: Flamebait) by Ribbit · · Score: 1

    Now, are 3dfx going to do this properly? Are they going to give XFree86/PI/etc their full cooperation, release the specs, maybe write some of the code themselves, and generally do the right thing? Or are we going to see essentially another Glide, where they make their own binary-only, x86-only releases, don't give the code back to XFree86, maybe try to tie it into Glide somehow, and generally try to keep the monopoly they think they have on 3D in Linux? We shall see... (BTW, it's my understanding that 3dfx's Windoze OpenGL drivers are not totally compliant, since they can only do full-screen rendering.)

    /Begin soapbox
    I cannot understand why people still think Voodoo is the best thing since sliced bread or whatever, and go out and buy Voodoo cards by the bucketload. They can't render into a window, can't do 32-bit rendering, don't have a full 32-bit z-buffer, can't render into a window, can't do AGP texturing, and still have that ridiculous 256x256 texture limitation. The only good thing about them is that they're still pretty quick. If you want a 3D card for Linux (or anything else actually), buy a TNT, or better yet, a G400.
    /End soapbox

    P.S. Keeping my fingers crossed for the Glaze3D...

  77. Re:My RIVA TNT *Rocks* on linux -- slower than win by Anonymous Coward · · Score: 0

    Blah blah, rocks schmocks, it's still a lot slower than using a TNT in Windows. Don't be an idiot.

  78. Wishful thinking. by Axe · · Score: 1

    which eliminates the stability problem

    You hope so. This Netscape crap freezes X dead - including keybord, on a regular basis. And that is not the only offending application. Yes, brave Linux heart is still beating under it, and I can drive to work to ssh to it, but that sort not a stable system, do not you think?

    BTW, is their a way to connect the keyboard thru some separate driver, which listens to a particular key combination to switch to separate console, so X can never freeze it out?

    --
    <^>_<(ô ô)>_<^>
  79. How can they.. by Axe · · Score: 1

    ..use 512x512 tiles? Pardon my ignorance, but I thought they can only use 256x256 textures, unlike better cards from nVidia and Matrox...

    --
    <^>_<(ô ô)>_<^>
  80. Compatibility? by MenTaLguY · · Score: 1

    Just had a thought... are DRI, DGA, the proposed anti-aliased font extension and so forth in XFree86 part of, or planned to be part of a current or future X11 spec? I've noticed that a lot of these things do not seem to be supported by non-XFree86 servers ... we're not inadvertantly embracing and extending X11 here, are we?
    ---

    --

    DNA just wants to be free...
    1. Re:Compatibility? by Anonymous Coward · · Score: 0

      GLX and DGA are X extensions. They aren't part of the actual X protocol, so they don't have to be implemented by every vendor. GLX has been part of SGI's X implementation for a while, and I think some of the commercial X servers for linux (and of course SGI) had DRI before XF86 did. However if you get down to it, yes we are "embracing and extending" X. However when you're releasing code under the XF86 license, is that really a bad thing?

  81. This is a Bad Thing by Anonymous Coward · · Score: 0

    Binary-only modules won't work with other archs (if they don't support PPC, we won't have PPC support); they can't be fixed by the users if some bug is found; after the hardware gets old the manafacturer won't upgrade the driver and you're stuck with it while it rots because of some unexpected new device or even a kernel change; and this is only the beginning.

  82. Go 3dfx! by Anonymous Coward · · Score: 0

    Why do you all have to tear into 3dfx when they CONTINUE to support their product under linux! I mean, how do you expect them to respond when they visit slashdot and see all this hatred and inconsideration. Personally, I'm glad to have a excellent glide library that gives me accelerated OpenGL. Sure, we can't see into the source of the library, and there may be a few microseconds of performance that we can't gain. So what? 3dfx has devoted themselves to supporting linux. Let's not hate them for it.