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.
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?
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.
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 ?
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);}
"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.
Actually, it's the other drivers that are behind
And Mesa happens to be at the heart of the OpenGL implementation in XF4...
whose OpenGL 1.2 implementation is not complete/100% conformant
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...
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"... :-(
Flames burst from nowhere
Anonymous Coward speaks
Wear your asbestos
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
Nice troll! I'll bite. Lessee, where do I start.
Why don't you do a little research occasionally?
--Joe--
Program Intellivision!
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
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.
/etc/X11/gdm-conf and _poof_ I could drag stuff from screen to screen to screen.
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
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.
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