XFree86 4.1.0 Reviewed

Patrick Mullen writes "The Duke of URL has just posted their review of XFree86 4.1.0. The review covers its new features, the fixes since 4.0.3, performance (2D and 3D) and even takes a look at what ground has been made in ATI, NVIDIA, 3dfx, and Matrox's drivers." Compares performance to windows where applicable and to X403. Looks like the speed gains are real. Hope it gets put into sid soon for us apt junkies.

Comments

Almost ready to upgrade

[Anonymous Coward]

Lately we've seen a new mature version of KDE (2.1), and new version of GNOME (1.4), a new kernel (2.4), and now Xfree86. With all this, I'm getting really temped to upgrade. The wise will wait for GCC 3.0 though. The new C++ ABI is going to break stuff everywhere, so a clean install will be recommended. It's getting very hard to wait though.

Re:Almost ready to upgrade

[gmhowell]

Big dittos to your post. With a caveat.

I managed to host the rpm database on my RH machine about a year ago. And in trying to upgrade stuff, finally got it so that gcc doesn't work, glibc is screwed up, etc, etc. Rather than rebuild everything, I'm going to take the chance to upgrade and switch distros (to Progeny for those who need to know.)

I was thinking along your lines (wait for GCC 3.0) but I'd rather not. I backed up all of my tarballs, and I'll wipe everything except /usr/local and /home. Install new distro. Now, when GCC 3.0 rolls around, I might have to reinstall again, but I've backed up the tarballs. Just reinstall them.

There is another trick: with each subsequent release, there are more and more apps available. Half of the tarballs of stuff I have installed on my RH 6.2 system are included as packages on Progeny (Storm/Corel/Debian/etc)

Re:Why X is slow.

[Adnans]

1) X runs on UNIX. Unicies are almost always server-oriented systems, and tend to have very short thread quantums. For example, the quantum on Linux 2.4 is 50ms (down from 100+ on 2.2).

This is simply not true. Both your 2.2 and 2.4 numbers are dead wrong. Linux on x86 has always had a timeslice of 10ms. It has always been 1ms on 64-bit Linux platforms (Alpha). BTW, you can modify the timeslice very easily by editting /usr/src/linux/include/asm/param.h and setting the HZ define at 1000. Yes, the timeslice is mostly dependant on this single define. You will notice that for x86 it is at 100 by default. To get the timeslice you simple divide 1000ms by the HZ value. So for 2.2 and 2.4 you get 1000 / 100 = 10ms. I have a standard patch that's applied to all fresh kernels that put HZ at 1000 on my boxes. It's kind of ludicrous to have 10ms timeslices on a 1.4GHZ Thunderbird *g*. Oh, and if you need smaller timeslices, witout having to modify your kernel lookup the manpage of sched_setscheduler

show much improved access times, even when the GUI is in a userspace server (as in BeOS or QNX)

X is in userpace.

2) It's badly designed

The design is about 20 years old, and still going strong. The developer didn't have the hindsight of what hardware would be developed over the years. Luckily enough they tought of X extensions. Oh wait, X extensions are bad right? Don't tell that to the Xv and RENDER extension that are taking full advantage of my cutting edge NVidia GPU!!

X uses the much more general (and much slower) UNIX domain sockets

Local sockets are really fast (and very low latency). For large transfers X uses shared memory anyway. And thanks to XAA the amount of communication is kept to a minimum.

...when GUIs like Photon (on QNX) implement all the features of X plus more in less than a meg, one has to fault elements of X's design

Try TinyX. Your arguments, while true to some extend, are really not convincing enough to call X "badly designed". You are using outdated facts to draw conclusions. X is here to stay. Whining about it is not going to make it less useful. You could spend your time better by helping out Be and BeOS, be-fan. A 3ms timeslice doesn't do me any good if it doesn't boot on my box. Too bad the juicy parts are closed source no??!

Oh, I finally decided to put my BeBox in long term storage. Perhaps in 20 years it will fetch a nice price. I'm betting it'll bootup witout too much trouble, assuming I can still find a CMOS battery that fits.

-adnans

Re:Serious Question

[wiredog]

Yes. In about 91 or so. That's when I decided to upgrade from VGA to an accelerated SVGA with, IIRC, 512K of on board memory AND a WordPerfect driver.

Great For Laptops!

[nlabadie]

One of the major problems I had running XFree86 on a laptop was having to switch between a port replicator (aka docking station) and using the laptop's display. For those of you that don't know, a port replicator lets you use a standard monitor, keyboard, mouse, etc. Switching between various XF86Config files got to be a royal pain in the arse.

So... those with laptops give this option a try in XF86Config:
Option "UseBIOSDisplay"

It lets you switch between monitors without changing the config file. Haven't had a problem yet.

Re:Tdfx

[PianoMan8]

Do you have the Creative Banshee? If so, that's your problem. Creative used underspec'd ram on some of thier cards. I talked with Daryll Strouse(sp?) about this at ALS last year (I happen to have these cards) and he was willing to put in an option "SlowRam" to use less aggressive timings on these cards, which would work. (The official TDFX drivers, may they rest in peace, had a similar patch applied, but it slowed down access for ALL banshee's with sgram)

Solution: contact me (clemej@pop3free.comCANNEDMEAT), my slashdot info is very outdated.), and I'll send you the patch from the X3 tree, you can find a way to apply it to X4. and then compile your own X. My attempts to make a SlowRam patch seemed straight forward enough, but never worked. Or, spend the 30$ and get a voodoo3. better performance, much more stable. I'm running X4.1.0 now on my Voodoo3 2000 PCI with DRI, and it runs great. Beats my old creative AGP banshee to a bloody pulp.

Staying with a buggy banshee means you're gonna have to recompile. A lot.

If that isn't your problem, will, then the best I can say is, IWFM.

pm.


- --

Re:snow on g200

[stilwebm]

That is fairly common when moving to new xservers on new hardware. It is usually the result of timing issues afaik. This type of bug is usually eliminated as more user feedback and testing help the developers with optimal timeing and acceleration code. Speaking of acceleration code, sometimes turning acceleration off eliminates the snow at the cost of speed. In any case, 4.1.1 will probably be much less snowy for you.

Re:Some Questions

[grammar fascist]

SELF-REPLY ALERT!

Do I have to recompile my kernel too?

No, idiot. Just find and compile radeon.o in the XFree86 source tree. Copy radeon.o (which is version 1.1.0) into /lib/modules/2.4.x/kernel/drivers/char/drm over the top of the existing one (which is version 1.0.0).

That worked. Greetz, grats, and thanx to all in the XFree86 team and their DRI buddies that made this work so well. Quake III is beautiful on my Radeon.

By the way, if you dual-boot, you can use a Win32 install of Quake III to play on Linux. Download the latest Linux point release from www.quake3arena.com. Change directories to one directory above your "Quake III Arena" directory on your Windows partition. Change its name to "quake3". Untar the point release. Change the directory name back to "Quake III Arena". Run quake3.x86. Isn't that spiffy?