Slashdot Mirror


XFree86 4.0 vs. XFree86 3.3.x

Patrick Mullen writes "I've recently compiled a comparison of XFree86 4.0 vs. 3.3.x. The review includes benchmarks, an overview on 4.0, the bugs still in 4.0 and a few other tidbits. " Its a bit sparse but its a good overview piece. It looks as if its definitely not for everyone quite yet.

12 of 122 comments (clear)

  1. Questionable benchmarks by bconway · · Score: 3

    The specs on the GeForce look nice, but I find the 3dfx benchmarks quite questionable. I installed X4.0 by wiping /usr/X11R6 clean and using a standard RPM install, followed by an RPM install of the Glide 3.x drivers. Quake 3 worked out of the box, and my framerates have been approximately 20% higher. I'm curious as to exactly how he configured his card and whether he was in fact using the correct drivers. This seems a bit odd. I've only heard good things about the improvements using the Voodoo3 cards from a number of people.

    --
    Interested in open source engine management for your Subaru?
  2. Another comparison. by Anonymous Coward · · Score: 3

    You can also find information comparing driver support between XF86 3.3.x and XF86 4.0 here at the XFree86 website. You'll find that many popular graphics chipsets have yet to be ported to XF86 4.0.

  3. XF86-4.0 is very fast for me. by Forge · · Score: 3

    It's also very slow. You see on my main desktop ( A humble P200 with 64 megs and a 4 meg S3-Virge ) it takes several minutes to load X. Most of that wait time you have a blank screen.

    Sure, X4 doesn't support many chips the X3 supports. However there is no need for it to support them as both versions of X are compatible and Mandrake has already demonstrated how to ship and install both.

    With a little refinement they will be able switch X version depending on Video hardware. And of course OSS means that every Linux and *BSD vendor can copy what they do at will.

    --
    --= Isn't it surprising how badly I spell ?
  4. Re:Mesa Less deisrable? by Emil+Brink · · Score: 3

    No, that sounds about correct. But the author is definitely somewhat confused, as this quote illustrates:
    GLX: This is SGI's OpenGL extension. [...]
    Um, using the term "extension" in the same sentence as OpenGL really makes people assume that you're talking about an actual API extension, but here this is not the case. GLX is simply the platform-specific glue that connects OpenGL to a platform's particular resources. In the case of GLX, the platform is the X Window System, of course. On Windows there is WGL (pronounced "wiggle"), and on Macs they use something called agl (no link, sorry). GLX also provides network transparancy, since that is a feature of X.

    --
    main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
  5. Some commentary... by adamk · · Score: 3


    "With the present state, 3dfx is actually behind on DRI drivers, which is rather surprising."

    They are behind for a couple reasons:

    a) Precision Insight (PI) was more concerned with taking advantage of all the cards features than they were with optimizations. This should hopefully be changing in the near future.

    b) 3dfx seems to be just as concerned with supporting the Voodoo4/5 when they're released as they are with supporting the Voodoo3, and PI has been working in that direction.

    "The only explanation I can come up with is because XF86-4.0 is less proven than 3.3.x 3dfx's drivers proved to be very fast even without direct hardware access, and without true OpenGL-which may be the reason why the new implementation is so weak. Which brings me to my next point..."

    In fact, the 3dfx has always used direct rendering for 3d acceleration under X, but now they are using Precision Insight's Direct Rendering Infrastructure (DRI), a different form of direct rendering.

    "nVidia pushed the drivers out the door almost immediately..."

    That is just wrong... It took an extremely long time for nVidia to release their drivers after they said they'd be releasing high performance 3D driver for 4.0.

  6. This is a lame review... by m2 · · Score: 5
    This means we'll start seeing more standard 3D acceleration on cards-not just 3dfx anymore. With the present state, 3dfx is actually behind on DRI drivers, which is rather surprising.

    Actually, it's the other drivers that are behind

    The new GLX extension is OpenGL 1.2 compatible, meaning here comes 3D graphics, CAD and other such professional uses. This is starting to make Mesa look less and less desirable

    And Mesa happens to be at the heart of the OpenGL implementation in XF4...

    especially after seeing how OGL 1.2 performs on nVidia's .90 beta DRI drivers.

    whose OpenGL 1.2 implementation is not complete/100% conformant

    Taking Initiative It's clear who really wants this. nVidia clearly is fighting for victories on both Windows and Linux-what next, Macintosh? nVidia pushed the drivers out the door almost immediately, and in some cases it shows, but in others the drivers prove to be exceptional for performance-even if unoptimized. If nVidia gets on the ball and optimizes the drivers, they're looking to destroy Windows performance. I've never seen performance quite this fast on the first release candidate. Now only if nVidia would get off their lazy asses and release something new, maybe from the Detonator 500 series of drivers. We can all wish, right? Matrox also looks to be getting their hands in things, as they always do. They made the push on Windows, and proved to be one of the first mainstream cards to have OpenGL, and again they're a pioneer. The more the better, I say.

    Which has very little to do with XF4, which is what is suppossed to being reviewed. Nvidia released a new server and a matching OpenGL implementation (without programmer's documentation or at least a dammed header, mind you). An own OpenGL implementation (or SGI's) is supposed to be behind it...

    Unfortunately, with all new releases, some things just don't work quite as planned. Since it's Open-Source some of these problems can be expected, and it is also free. Here's a run-down of the problems faced in this release:

    And you are comparing apples and oranges here... it doesn't say which Voodoo driver is being used, and I'd suppose it's compared against the nVidia recently released drivers. The point is nVidia says their drivers are beta, while the Voodoo ones are still in development.

    I'm kinda surprised taco posted this, next thing he'll post is my (rather long) email that says "XFree86 sucks" or "XFree86 rulez"... :-(

  7. Re:Haiku by 575 · · Score: 3

    Flames burst from nowhere
    Anonymous Coward speaks
    Wear your asbestos

  8. Virtual Consoles cause crashes for me by robwicks · · Score: 3

    If I run X using startx, then switch to another VC using ctrl-alt F2, then log on as root and start an X session to use some graphical tools, then quit the root session, if I do Alt-F7 to get to the original session, I get a crash every time. I suppose a positive result of this is that I use sudo much more frequently, but I don't even recall some of the names of some of the KDE tools to run them from the command line. It's a bit inconvenient. Apart from that, things work fine. Q3Arena works well, though I don't see any improvement when I activate r_smp 1 to get SMP support. In fact, I get about .4 fps lower than with r_smp set to 0. I'm still too new at this to really troubleshoot that properly, though.

    Mandrake 7.1 beta, PII333 SMP x2, 256MB RAM

    --

    Logic ... merely enables one to be wrong with authority. -- Doctor Who

  9. Re:XFree86 4.0: it's all about marketing by Mr+Z · · Score: 3
    How many of them have given you a condescending smile when you mentioned that you use X-Windows 3.x? In their mind, you're just another person who can't keep up with technology. So is the FSF just trying to one-up MS in their own game by releasing XFree86 4.0? Seems like it to me.

    Nice troll! I'll bite. Lessee, where do I start.

    • First of all, until XFree 4.0 came out, most people didn't give a rodent's sphinter what version number X server you were running. X was X. XFree 4.0 changes that a bit since it does provide a huge boatload of features. But still, I don't think I've ever bothered to talk about what version X server I run with almost anyone else. For most things it just doesn't matter. Which brings me to my next point...
    • The version numbers for an X server do not compare to the version numbers for Microsoft Windows! It's a bit like comparing a JDK version number to Internet Exporer's version number -- it does Java, right? Wrong. "Microsoft Windows 3.x" vs "Microsoft Windows NT 4.0" is a huge difference, since it refers to the whole OS. The closest thing you could compare to is, perhaps, Linux distribution version numbers, which I do agree are inflated a little.
    • The FSF doesn't produce XFree86. The XFree86 Project, Inc. does. XFree86 even comes under (and this is important) a non GPL license . The FSF would never do such a thing.

    Why don't you do a little research occasionally?

    --Joe
    --
  10. Performance for XSHM extension also went up by Jorrit · · Score: 3

    In my Crystal Space engine which can also run in software rendering mode I noticed a big improvement in performance (from 25 FPS to 31 FPS) when going from XFree 3.3 to XFree 4.0. This has nothing to do with hardware rendering. I'm talking about software here. Other people reported this too.

    I wonder what happened there?

    Greetings,

    --
    Project Manager of Crystal Space (http://www.crystalspace3d.org). Support CS at http://tinyurl.com/cb3x4
  11. Multi-headed works well. by gukin · · Score: 4

    For the last few years, I've used metrolink's multi-headed server. For $40 it was a steal (at least compared to XiGraphics $350 server and the multi-headed stuff on our RS/6000's.) It was easy to set up, install and reletively stable. It didn't work perfectly though, it left the mouse pointer behind on one of the screens and got "weird" on some scrollbar functions.

    I compiled and installed XFree86 on my RH-6.1 system and, using xf86config, got my first head going in a few short minutes.

    I then read _gasp_ the manual page for XF86config which told me everything I need to do to set up the multi-headed stuff.

    The documentation (if you bother to read it) is well written and very usable.

    Once I got the multi-headed stuff going add +xinerama to /etc/X11/gdm-conf and _poof_ I could drag stuff from screen to screen to screen.

    I now have a three headed beast with one AGP Matrox G200 and two Matrox Millenium II PCI cards.
    Performance is completely acceptable and it is really cool that I can define different monitor types per head.

    My G200 is driving a 21" while the two Millenium II's are running old Viewsonic 7's.

    The Xinerama feature is SOOOOO handy. I can drag unimportant stuff to the outboard monitors and use the big central for the important stuff.

    XFree86 4.0's performance and flexibility is FAR superior to ANY other multi-headed X-server I have used.

    If you can't read a man page and don't need Xinerama (oh yeah and have lots of monitors laying around) Metrolink is a good way to go.

    Still, reading a man page is not too much to pay.

    Oh yeah, the RPM's for RedHat are available via rawhide.

    Gee I hope I didn't sound too stupid.

  12. Crock by CAIMLAS · · Score: 3
    Heh. I read this little write up last night (well, early this morning) while I was looking for info on getting OpenGL/Quake3 in XF86 v4 working with my G400. (Anyone able to help me out? I'm not sure where to start. I have X4 installed, but don't know if it's installed right, etc..)

    Even with my limitted knowledge, his article/write up seemed off color and slightly unfactual. (re: MESA not being in X4's implimentation of GL). It surprises me that the slashdot people don't read the articles themselves before posting them to slashdot, in order to check and see how factual they are. Or maybe they do, and just overlooked it. And then again, maybe they leave the crap-testing to moderators and posters. :)

    -------
    CAIMLAS

    --
    ~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers