Slashdot Mirror
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.
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.
--
Forget Napster. Why not really break the law?
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Just FYI. From the mailing list, I believe it could happen.
And it is the first GCC (maybe the first released compiler) to do so, so I'd say GCC 3.0 has a lot to do with it.
Someone mentioned on the dri-devel list that the modules that ship with XFree 4.1 are newer than any that ship with any kernel.
It may not be in Sid yet, but there are packages out there for Woody.
deb http://people.debian.org/%7Ebranden/ woody/i386/
deb-src http://people.debian.org/%7Ebranden/ woody/source/
My Slashdot account is old enough to drink...
Yes. When I first upgraded one of my machines to an S3 accelerated card, the non-accelerated ones seemed unbearably slow. However, even today, an opaque move of a large window can cause the machine to become less responsive. If the X server can help minimize this, so much the better.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
I don't think so. The length of a jiffy (the timer interrupt) in Linux is 10ms. However, the quantum is 50ms. Most processes are not preempted within the 10ms jiffy.
If there is no other process to run (with a higher priority) of course the kernel will let the current process run its full timeslice. However, any process that needs attention and has a higher priority than the current running one preempts it and gets to run (within 10-20ms). Scheduling quantum doesn't matter at this point. If you push up the HZ counter to 1000 (1ms timer interrupt) you can pretty much guarantee a soft-realtime process that needs attention every few ms to run correctly , assuming you make sure it has a higher priority than normal. You will notice that properly written apps do exactly this.
That's my point. QNX and BeOS both run in userspace, just like X, and run a good deal faster.
"run a good deal faster", and what runs a good deal faster? The BeOS UI is certainly much slower on my box these days, but I suspect that has something to do with the AMD-challenged optimizations in the Be kernel. Haven't tried QNX recently. Point is that with properly prioritized processes you can make Linux just as responsive as for example BeOS. The advantage BeOS has is that it does this automatically for you, it's a single user OS, with no security. (I'll take multi-user Linux over it anyday though!)
t they are not transparent to applications
What do you mean, not transparent?
Umm, the BeOS messaging system can shunt 90,000 messages per second around the system (on a PII 300). Nothing on UNIX is anywhere *near* that number. Even QNX can't do above 40K.
Where are you getting these numbers from? And what constitutes sending a message?
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
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).
/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
...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
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
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.
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
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
It's not, unfortunately - I've got the same problem with my Diamond Monster Fusion AGP (as does the reporter of the bug in DRI's sourceforge buglist, though he's got the PCI version). The Banshee Bug has been in the DRI since at least early April's CVS.
I'm hoping they get it fixed soon - I've been itching for XVideo support, which HAS been fixed (but I can't use because of the banshee bug corrupting everything...). The bug was assigned a while back now - my guess is it'll be fixed soon (the fix may be delayed because the DRI team is evidently busy moving to Mesa 3.5...)
Or, spend the 30$ and get a voodoo3...If I can manage to find a Voodoo3 AGP locally for only about $30, I may just do that...
---
Hacker Public Radio is our Friend
For what it's worth, this bug has been in DRI's sourceforge bug database for about a month and a half now (I went to report it myself a couple of weeks ago and found someone else already had, so I just added what little extra info I had about it to the discussion...)
Oh, and if you go to look it up, I'm not the one who reported it as "WTF ARE YOU GUYS THINKING?!?!", so no flames, please...the bug report can be found here.
---
Hacker Public Radio is our Friend
Why wait? Do it like the rest of the world! It's easy and fun! Like so:
> sh Xinstall.sh
Then you don't have to be at the mecry of package maintainers. You'll have control over your own system, and in no time you'll be livin' la vida Libertarian.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
I just installed 4.1 on my G400 (yes, yes... but it's close, and I'm curious if you had the same problem)...
I had never been able to enable antialiasing on both heads; the primary looked okay, but the second was screwed up. Now, with 4.1, both are "sort of there"... large rectangular blocks of text are simply missing, but if I highlight them in Konqueror, they reappear, and stay there when I remove the highlighting. A Control-A in each web page seems to fix it.
It's a shame - it's just so darn *pretty* to use these antialiased fonts, but I just can't get aa (or GL) to work if I'm using dual-heads (GL *does* work just fine if I drop it to using just a single head, but as soon as I reference that second head in XF86Config, GL dies).
Bah... I wish I had the time to scroll slowly through logfiles... Grrrr... I didn't have time to fix it then, and I won't have time now, dammit.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
The 'paradoxical dependencies' is right on because in several instances, as an example: libstdc++#### depends on libc6####, yet libc6#### depends on libstdc++####
Not on my system. apt-cache showpkg reveals that libstdc++ is dependent on libc6, but the reverse is not true. I'm not entirely sure what that has to do with XFree, anyway, since AFAICT there aren't any dependencies between X and libstdc++. I'd love to show you the proof, but it's about 5100 lines long, and I don't think the lameness filter will let that pass.
Unless you have tried to upgrade the XFree86 >4 on your existing debian system and had none of these problems then fuck off.
What's ">4"? If you mean 4.1, then no, I haven't tried, but I am tracking unstable, which is currently at 4.0.3-4, and the last time I had a problem was, IIRC, during my initial move to 4.0, when there was a broken dependency deep in the system, though I can't remember if it was X-related (whoops, run-on sentence there). In any case, it was promptly fixed, though I'd worked around it by then, anyway. (Come to think of it, I may have been in worse shape then you, screwed libs and all, but I, having used Debian for a whole two weeks, managed to rebuld everything by stripping the system out and replacing everything by hand in one night.)
And yes, many others have had the same problems whether using the apt-get route, dselect, etc.
True, and usually they don't what the fsck they're doing, but have decided that since the package system won't conform to their declued view of the world that it must be "broken", and its their job inform everyone of this fact. Some of them are just trolls, too.
yes, the fact that you are clueless... if you want support (I'm looking at dualhead, dualrefreshrates, dual resolutions under 4.03 so there are drivers) go to www.matrox.com or especially:l /2 001/linux_powerdesk.cfm
http://www.matrox.com/mga/media_center/press_re
install a few files and run this powerdesk for linux and your xfree works like a charm. (ps, you have to cut and paste this link, you can't click).
nosig today
Your entire post has made no sense. You have yet to explain what exactly goes wrong, and why you cant upgrade the standard librarys. If any upgrading was done to your standard librarys those would be the upgrades that are done anyways.
The only upgrades this X install will do are packages built directly from the X source. Everything else is pulled from the woody dist.
Yes, thats right, its not going to randomly upgrade packages because it has "paradoxical dependencies", its going to upgrade everything that would have been upgraded if you ran "apt-get upgrade" anyways.
Please stop spreading FUD, or at least give a reason why these things are bad.
One more point: maintainers dont control which portion of the libs are installed in the new one and whatnot . . . I dont know how dpkg works internaly, but basicaly it wipes out the old package, and write over *ALL* the old files with files from the new package. Anything else would be non-sensical. To get your old stuff back just re-install the old package. this will wipe out the new package, and install the old one
Journey
I currently run a SuSE 6.3 system with a 2.2.14 patched kernel (from standard 6.3 2.2.13 kernel). I have whatever version of X was included (3 something, probably), and use KDE 1.3.
I have thought about going to X 4.x, and KDE 2.x - but as I am still shakey about breaking my system (it was a bitch doing the kernel patch - just to get the ZIP drive working, only then breaking the sound, having to install and configure ALSA, etc) - everything runs OK on it right now. I just would like to get some of the extra features.
Has anybody done anything like this, and what was your experiences? How difficult would such a major upgrade be? Would I have to patch the kernel again (one thing I have wondered is if I could just grab the latest patch for the kernel and apply it against my source, or if you have to do the patches incrementally - or if I would just have to grab the whole source, etc)?
Or, should I do what I am thinking of doing - scrap it all, get a reasonably late distro, install that and move my data over?
Any recommendations?
Worldcom - Generation Duh!
Reason is the Path to God - Anon
Yeah, 80X50 text, and it sped up scrolling wonderfully.
Best Slashdot Co
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.
Best Slashdot Co
Any chance it works with an AMD 761 northbridge? I had a 32MB DDR Radeon working fine on a VA-503+ with XF86 4.0.2, but my attempts at getting the same card working on an M7MIA have been somewhat less than completely successful (read: hasn't worked at all). Others have said it'll work if you shut off acceleration, but what's the point of doing that? I might as well yank out the Radeon and put my Xpert 98 back in if I'm going to do that.
20 January 2017: the End of an Error.
i agree, x sucks at gaming, its the truth, i had the same problem with QUAKE damnit, both quake 1 and 2 ( yes i know it not x ) .
on several machines, just please, let go of your dreams on linux as a gaming machine. i say - dualboot if you need linux for something else than your server needs.
Actually, KDE being slow has less to do with X and more to do with linking, loading, and C++ virtual function use.
Check out:
http://www.suse.de/~bastian/Export/linking.txt
Besides, moving XFree into the kernel would be of dubious value at best. Moving certain critical _parts_ of XFree into the kernel might be a win, like the graphics drivers. After all, why the heck should a user space application like XFree be doing PCI management?
--
"I'm too old to use Emacs." -- Rod MacDonald
Try running XF4.0.1 on LinuxPPC with the Rage Pro driver that ships in the stable build.
Its a pig.
I imagine with the driver work and the inclusion of DRI, that 4.1.0 will be a massive improvement for Linux/PPC users.
I gots ta ding a ding dang my dang a long ling long
Obviously not (in the past 5 years or so) because in that case most people turn off features until everything runs fast enough. But i bet even nowadays there are people sitting in front of their PC saying: "Wow, look at all the stuff i can do now and the cool GUI, two years ago i wouldn't have thought it possible without enduring agonizing responsetimes".
Yup, i admit it, i think transparent window moves look nice, i would live without them, if they were slow or jerky, but now that i can have em i switch those features on. So one could say that most of the speedgain goes to (maybe unnecessary) eyecandy, but i don't think that is a bad thing.
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
Oh god. He pointed out X sucked! Blasphemer! Keep it coming, baby, got plenty of karma to spare ;)
A deep unwavering belief is a sure sign you're missing something...
Yuck. Factual errors all over the place...
This is simply not true. Both your 2.2 and 2.4 numbers are dead wrong.
>>>>>>>>>>>..
I don't think so. The length of a jiffy (the timer interrupt) in Linux is 10ms. However, the quantum is 50ms. Most processes are not preempted within the 10ms jiffy.
X is in userpace.
>>>>
That's my point. QNX and BeOS both run in userspace, just like X, and run a good deal faster.
The design is about 20 years old, and still going strong.
>>>>
It's still alive... But so is Strom Thurmond.
Luckily enough they tought of X extensions. Oh wait, X extensions are bad right?
>>>>>>>>>>>>
Yes, extensions are by definition bad when they are used to implement core functionality. OpenGL extensions suck for the same reason X extensions suck: they are not transparent to applications. All apps should be AA enabled automatically (user-configurable, of course!) The fact they are not is an inherent weakness in the extension mechanism. Sorry to say this, but MS has the right idea. Take a look at DirectX for an API that allows old apps to automatically take advantage of new advances.
Local sockets are really fast
>>>>>>>>>>>
Umm, the BeOS messaging system can shunt 90,000 messages per second around the system (on a PII 300). Nothing on UNIX is anywhere *near* that number. Even QNX can't do above 40K.
Try TinyX. Your arguments, while true to some extend, are really not convincing enough to call X "badly designed".
>>>>>>>>>
Does TinyX have all the featues of QNX Photon? Hell, Xfree86 doesn't have all the features of Photon!
As for BeOS, you're comments are irrelevent. I mentioned it for technological comparision, not political debate. Though I too support OSS BeOS, it is not an issue in this thread. Not everything I post is a Linux-sux BeOS rocks rant.
A deep unwavering belief is a sure sign you're missing something...
If there is no other process to run (with a higher priority) of course the kernel will let the current process run its full timeslice. However, any process that needs attention and has a higher priority than the current running one preempts it and gets to run (within 10-20ms).
>>>>>>>
True. However, that requires processes to have a higher priority. However, on a normal system, Linux doesn't automatically manage these priorities. While "goodness" does have some effect, the Linux sheduler doesn't use tricks like the Windows sheduler does to make sure that GUI apps get fast response times. If you look at the case study of Win2K in Tannenbaum's new book, you'll see that Win2K does all sorts of priority mucking to make sure that GUI apps have a higher ability to preempt than other apps. While this might be bad for a server, or a generalized system, it certainly does wonders for GUI response.
"run a good deal faster", and what runs a good deal faster? The BeOS UI is certainly much slower on my box these days, but I suspect that has something to do with the AMD-challenged optimizations in the Be kernel.
>>>>>>>.
BeOS doesn't properly support the mtrrs in AMD chips.
Haven't tried QNX recently.
>>>>>>
You should. Not only does it have the nicest fonts I've ever seen, but it is fast as all hell.
Point is that with properly prioritized processes you can make Linux just as responsive as for example BeOS.
>>>>>>>.
On a desktop or workstation OS, this shouldn't be necessary. The OS should manage that. Besides, I've been running X at -20 as long as I can remember, and while it improves the speed, it still doesn't work as well as Win2K or BeOS.
The advantage BeOS has is that it does this automatically for you, it's a single user OS, with no security. (I'll take multi-user Linux over it anyday though!)
>>>>>>>>
Why? On a workstation, what's the point?
t they are not transparent to applications
What do you mean, not transparent?
>>>>>>>>
For example, in DirectX, an app uses whatever features the API has available. If the features are not implemented in hardware, they are emulated. (Or, in the case of some 3D features, just not implemented. In these cases, however, you get fine-grained information about the exact capabilities of hardware, so it is quite easy to enable turning on and turning off of features.) In either case, when hardware that supports that feature becomes available, the software automatically takes advantage of it, no recompilation, no patches, no nothing. Thus, if X had this design, all apps would automatically take advantage of whatever features were available. AA text could be done without requiring application support. Different rendering back-ends could be put in without messing with apps. In general, lots of stuff that X should do automagically, but can't. While this is more of a problem for OpenGL (where features are introduced monthly) X isn't immune to it, as evidenced by the silliness of Render. While DirectX in reality has deviated somewhat from the ideal of feature transparency, it still does a hell of a better job than any extension mechanisms. This is evidenced by the fact that developers sternly told MS not to make DirectX extendible.
Where are you getting these numbers from? And what constitutes sending a message?
>>>>>>
A simple program shunting data from one app to another. The messages were various sizes, and used whatever IPC mechanism was native on the OS (ports in BeOS, send, recieve in QNX). With 32 byte messages (the size of an X packet) BeOS hit 90,000 messages per second on a PII. QNX was in the 40s. With big messages (10K and up) BeOS could move data at memcpy speeds approaching 400MB/sec.
A deep unwavering belief is a sure sign you're missing something...
Don't forget the XVideo/Render/RandR code that the developers are working on. New releases often contain substantial upgrades for video drivers which can improve both speed and stability.
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.
I am staying on XFree86 v3.3.6 + UTAH until either nVidia opens their drivers or I get another card. Unless nVidia changes their stance I will NOT be purchasing an nVidia card in my next machine.
:(
BTW, I run FreeBSD so not even the closed source drivers are an option.
Does anyone know if the XFree86 drivers support minimal hardware-accelerated 3D graphics on a TNT2 Ultra? Maybe close to the UTAH drivers?
It's kernel, not kernal.
Hello, my name is Robert Lerner, and I pronounce Lernux as "99% cpu"
I had a 3dfx Voodoo 3 3000 a while back, and had pretty much the same problems you mentioned with blender. Not only blender, but also AC3D and - here's the kicker - the problems were present on the Windows versions as well.
That in mind, it might be a card issue more than a driver issue.
As far as new cards, I have a Nvidia Geforce MX that's fully supported. The drivers are binary, and once I got the newest ones from NVidia, I had no problems with them.
If you want open-source only drivers, I believe that ATI's are - though I don't know how well they're supported.
-Denor
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.
- --
- --
"I Hate Quotes" -- Samuel L. Clemens
Download source, compile yourself.
Are all so lazy?
--
--
I like to watch.
No, I started in the middle, and then read the post letter by letter first to the right, and then to the left. That way you get both sides of the story, if you see what I mean.
---
Slagborr
Some of us have to use the FB Xserver. Since framebuffer support is already less than fast, any speed improvments are quite welcome.
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.
I'm on an AMD board too. UT isn't rock solid here either, but I thought that was just me playing around with a few things, as it was being fine until I started piling on the clever stuff. For some reason its a lot more stable if I run it at my X Desktop resolution, which shouldn't make any difference. As you've got a custom UT user, try setting its normal X desktop to the same as you want for UT.
I agree that Quake 3 Arena is sweet on Linux; even if the benchmarks say its the same as Windows, subjectively it felt much nicer for some reason.
The main thing that impressed me with UT though was that compressed textures work, which makes a huge difference. Also speed generally (because the textures fit in memory better with my 32Mb Geforce) is a vast improvement over the stutter factory that is running UT over 640 with medium res textures under Windows.
"I Know You Are But What Am I?"
This is something thats measured in hundredths of seconds for Pete's sake...
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
This is the major point for me. Especially since I sometimes throw together frankenboxen with a wide variety of obscure parts. [I obviously need the education]
Still looks very promising. Tbe proverbial step in the right direction.
Check out the Vinny the Vampire comic strip
"It is a greater offense to steal men's labor, than their clothes"
I am Voodoo3 owner. New XFree86 works faster, and more stable. 4.0.3 was bad - no Xv support, troubles with console and framebuffer. However - OpenGL in current CVS (and 4.1.0) is still broken. In all tests or benchmarks you just write about Quake or UT, never about less popular stuff. There are serious problems with Blender for example (but works much better than before!). When I use software renderer - everytihing is OK, but slow. When I turn on hardware accelerated 3D - some object are not drawed, blinking, etc... you won't notice it in pure OpenGL apps, but try gtkglarea, SDL/paragui or anything else with 2D widgets...
Should I change video card? But what should I choose? Nvidia has binary only drivers, tdfx dirvers are buggy... is it any other way?
I'd be happy if someone got it to compile for Solaris and packaged it up. It seems that a key part, an include file if I remember correctly - prevents it from compiling the server itself. It's under the sun stuff. I don't have the information handy offhand, but I could reproduce it with differing versions of XFree86 as well as the X.org version(s). I know it's possible... I just want Xinerama and Render support for Solaris! Is that so wrong? :)
I can't say how stoked I am to try the render, xinerama and truetype support finally, under Solaris...
Props to the XFree team!
1) First, this is great news for Radeon users. IIRC, though, when I tried the Radeon DRI from Sourceforge, I had to recompile my kernel without its DRI modules and use their modified X's. I already know that I'm going to have to download the source tarball to use the DRI in XFree86 4.1.0. Do I have to recompile my kernel too? (Not that it's hard - just wondering.)
2) There was a bug in DRI that would freeze up the entire system. I could always reproduce it by playing a few minutes of Quake III. Does anybody know the status of this?
3) (Stupid luser question) Where can I find info on how to do AA fonts on XFree86?
Thanks in advance for any good answers.
I got my Linux laptop at System76.