Debian Sid Moves to X.Org

debiansid writes "Yes, Debian sid finally has X.Org. The Changelogs suggest that some work has been taken from the Ubuntu packages of X.Org. Here is an article that gives details on how to migrate to X.Org on sid. This article, by the way, has been posted from an X.Org based X-Window System, and it really IS much faster than XFree86."

Comments

Oh really?

[Anonymous Coward]

This article, by the way, has been posted from an X.Org based X-Window System, and it really IS much faster than XFree86."

Last I checked, the only difference between the two was the license and a couple of new drivers. Certainly nothing to explain a "much faster" performance. Perhaps you could explain to us in a little more detail, how your's is "much faster"? Does it have anything to do with the fact that you are using it on a newer and more powerful machine?

Re:Oh really?

[Sodki]

Initially, X.Org was just a fork of Xfree86, but no more. Good "under the hood" work has been done recently in the X.Org field.

Re:Oh really?

[irtza]

Speaking of speed. Has anyone tried DirectFB? I hear its supposed to offer more features/speed, but it seems a bit too betaish for me to try it. Was wondering if anyone more brave has tried it with a Radeon 7000. Would love to leach some info off of them.

Re:Oh really?

[niko9]

Last I checked, the only difference between the two was the license and a couple of new drivers. Certainly nothing to explain a "much faster" performance. Perhaps you could explain to us in a little more detail, how your's is "much faster"? Does it have anything to do with the fact that you are using it on a newer and more powerful machine?

Not true. look here

I have both the Radeon (at home) and the Intel i810 drivers in use witht he new Xorg in Sid, and performance in 2D is a little faster.

Using transparency with the damage extension is a whole other story....

My thanks to all who worked hard on getting Xorg into debian.

Re:Oh really?

[niko9]

I forgot to add:

* ATI Radeon driver updates:
o Merged Framebuffer support (dualhead with DRI)
o DynamicClocks option (reduced power usage)
o Render acceleration (r100, r200 chips only)
o Support for new ATI chips (R420/M18, R423, RV370/M22, RV380/M24, RS300)
o DRI support for IGP chips
o Xv gamma correction
o Updated 3D drivers
o Many other small fixes
* Chips driver update
o Improved BE support
* MGA driver updates
o Support for DDC and DPMS on second head on G400
o Updated 3D driver
* Neomagic driver updates
o Support for Xv on pre-nm2160 chips
o Pseudocolor overlay mode (=PseudoColor emulation)
o Improved support for lowres double scan modes
* i810 driver updates
o Dualhead support (i830+)
o i915 support
o New 3D driver (i830+)
o i810 driver is now supported for AMD64
* S3 driver updates
o Support for additional IBM RAMDACS
* Savage driver updates
o Pseudocolor overlay mode
* SiS driver updates include
o output device hotplugging
o lots of fixes for 661, 741, 760
o extended interface for SiSCtrl?
o extended LCD handling (allow more modes)
o HDTV support (480p, 480i, 720p. 1080i; 315/330 series)
o Added video blitter Xv adapter (315/330 series)
o extended RENDER acceleration
o SiS driver now supported on AMD64
* New Voodoo driver (Alan Cox)
o Provides native (glide-less) acceleration and mode setup for voodoo/voodoo2 boards

Re:Oh really?

[dresgarcia]

I believe it was x.org 6.8.2(on my mac so I can't check) that was a big release, after installing it I had noticeable performance improvements.

Re:Oh really?

[Curtman]

A while back, I had looked into what would be involved in setting up a X.Org traffic weekly/monthly/whatever. If anyone is interested in doing this, I have some info from Zack Brown who does Kernel Traffic about how he makes it all happen. Something like that for the various X.Org lists (DRI-devel, and the X.Org lists themselves) would be very helpful I think. I wish I had the time and patience to make it happen myself. :(

I think it would be very helpful for attracting new developers if people could easily keep tabs on what is going on under the hood.

Re:Oh really?

[Anonymous Coward]

No, it's true. I upgraded to Xorg and it's much snappier now!

Re:Oh really?

[Anonymous Coward]

So Xorg has out-of-the-box support for 3D acceleration with Radeon (R100) series cards? I have a 7500 and I'm currently on XF86 with the DRI drivers, but I'd be interested in using the Debian Sarge backports to get Xorg on my rig if I could keep my 3D acceleration.

Re:Oh really?

[Anonymous Coward]

Initially, Xfree86 was just an x86 optimized fork of the original X server. Only on /. would you be modded +5 informative!

From wikipedia:

X.Org and XFree86

In May 1999, the Open Group formed X.Org. X.Org supervised the release of versions X11R6.5.1 onward. X development at this time was moribund [8]; most technical innovation since 1992 had taken place in the XFree86 project. In 1999, XFree86 joined X.Org as an honorary (non-paying) member [9], encouraged by various hardware companies [10] interested in its use with Linux and its status as the most popular version of X.

By 2003, while Linux's popularity, and hence the installed base of X, surged, X.Org was all but inactive [11] and active development was largely carried out by XFree86. However, there was considerable dissent within XFree86. It was perceived as far too cathedral-like in its development model; developers were unable to get CVS commit access [12] and vendors had to maintain extensive patches [13]. In March 2003, Keith Packard, who had joined XFree86 after the end of the original MIT X Consortium, was expelled with considerable ill-feeling [14] [15] [16].

X.Org and XFree86 began discussing a reorganisation suited to properly nurturing the development of X [17] [18] [19]. Jim Gettys had been pushing strongly for an open development model since at least 2000 [20]. Gettys, Packard and several others began discussing in detail what was needed for the effective governance of X with open development.

Finally, in an echo of the X11R6.4 licensing dispute, XFree86 released version 4.4 in February 2004 under a more restricted license which many projects relying on X found unacceptable [21], particularly as it was held to be incompatible with the GNU General Public License [22]. This caused great controversy, and many considered the time was ripe for a fork [23].

changelogs

[bonk]

Ubuntu changelogs suggest some work was taken from Debian as well.

Re:changelogs

[Jeff DeMaagd]

Ubuntu changelogs suggest some work was taken from Debian as well.

I would imagine that is the case, and I don't think anyone is pretending that it isn't.

While I think it is nice that Ubuntu is contributing to Linux, I am curious why it had to be the case, wouldn't that make Debian distribution development the slowest of the major distributions?

Re:changelogs

[Anonymous Coward]

GP was funny. Laugh.

Re:changelogs

[Anonymous Coward]

What I want out of every one of you is a hard target search of every gas-station, residence, warehouse, farmhouse, henhouse, outhouse and doghouse in this area. We will not stop until we find the humour that was lost on you.

No, its probably because in reality

[DaedalusHKX]

They're using "fglrx" drivers from ATI instead of the default 2d "ati" drivers :)

But what do I know, it only quadrupled my framerate in OpenGL apps. So all it comes down to, is probably much newer or more complete video drivers.

Re:No, its probably because in reality

[Anonymous Coward]

The free drivers are not just 2D. On some Radeons you can get hardware OpenGL working with them. (Though this was true in XFree86 also.)

Re:No, its probably because in reality

[ewhac]

They're using "fglrx" drivers from ATI instead of the default 2d "ati" drivers :)

Yes, but is ATI's support of suspend-to-disk still broken? 'Cause I've got this laptop here, you see...

Schwab

Re:No, its probably because in reality

[CarpetShark]

Rage chips, too.

One complication...

[stevey]

One complication to the upgrade not really covered here (I wrote that article) is the simultaneous C++ ABI transition Debian Unstable is going through.

This means that upgrading might cause you to loose a lot of packages like gdm, etc.

So if you try the upgrade and apt-get, or aptitude demand you remove lots of packages then the reason is the C++ ABI change - and if you simply wait a few days/weeks it should resolve itself.

At the time the article was posted things were less bad.

Re:One complication...

[ansible]

It would be really nice if Debian started another release process right after the transition to X.org and the C++ ABI are finished.

I really like Debian, and I'd prefer not to wait a couple years for the next release. :-)

Re:One complication...

[ewe2]

Actually the only problems I'm having is losing packages due to the GL library package rename and conflict. Why couldn't they contact the blender, audacity, vlc or csound maintainers for instance? Yes I know it's sid, that's not an excuse for bad communication. This, more than anything is going to get Debian a bad reputation.

Re:One complication...

[DrSkwid]

Watch out when you loose those packages, they tend to be hard to catch and can hide out in the crawl space!!

Re:One complication...

[poopdeville]

You know it's sid, but apparently don't know what that means. Sid is an experimental fork, recommended for use by Debian developers only. It is highly unstable, and Debian never claimed otherwise. If you want to use Debian with Xorg, wait at least until it gets into Testing.

Re:One complication...

[Pflipp]

Why, o why do they always make changing the C++ ABI such an effort? It takes some credibility out of C++ as a stable lower-level programming target if such a relatively frequently occuring change in the core obsoletes so much essential packages.

(Oh and please, don't make any sharp remarks about the quality of C++ as a language that I have already swallowed ;-)

Re:One complication...

[Anonymous Coward]

The glibc transition wasnt exactly a walk in the park either.

Re:One complication...

[InvalidError]

When GCC changes the Application Binary Interfaces (ABIs), wholesale breakage is unavoidable until everything is at least recompiled... and adjusted wherever people use ABI-bound wizardry to pull off some stunts such as runtime code generation/modification to setup dynamic library function stubs.

GCC's ABIs are usually changed to fix flaws and increase efficiency. They do not change that often for the older architectures where common practice and optimal sequences are well documented.

Re:One complication...

[thomasweber]

> Why couldn't they contact the blender, audacity, vlc or csound maintainers for instance?

You mean, like in this email in April:
http://lists.debian.org/debian-release/2005/04/msg 00153.html
or that one in July?
http://lists.debian.org/debian-devel-announce/2005 /07/msg00001.html

(Debian Developers are expected to read both of these lists)

Re:One complication...

[ArbitraryConstant]

"Why, o why do they always make changing the C++ ABI such an effort? It takes some credibility out of C++ as a stable lower-level programming target if such a relatively frequently occuring change in the core obsoletes so much essential packages."

The GCC people are the ones changing the ABI, and they're the ones losing credibility.

Re:One complication...

[steffl]

yes unstable is unstable but it's the only way debian is usable as a desktop distro for lot of people. Stable is too old (HW support, lack of new version of software like gnome, kde, openoffice etc.).

Considering lack of other choices (within debian) unstable should be treated as first release, not as a playground for developers. Experimental is a playground for developers.

We have C++ ABI changes and x.org changes and pretty much no openGL packages are usable and I guess it will soon become even worse (because of C++ ABI changes).

It seems like it would be better to do changes that break HUGE number of packages in experimental first, then, once at least most of the packages are updated, move them to unstable.

As far as testing goes - it looks more like abandonware then realistic choice, yes, there are fewer problems there but they take a lot longer to fix etc. I went with testing for awhile but my system was broken all the time, it happens a lot less with unstable.

Re:One complication...

[Anonymous Coward]

The GCC people are changing the API as the enormously complex C++ standard changes beneath them. It's C++ that's losing credibility (frankly anyone who can get a reasonably compilant C++ compiler out the door deservces praise)

Re:One complication...

[stevey]

Stable is too old (HW support, lack of new version of software like gnome, kde, openoffice etc.).

Stable has only been released a month and a half ago - so it's clearly not out of date too much.

Sure if the release of the next Debian Stable, codenamed etch doesn't happen for another two years then it will be outdated. But right now it's not.

Re:One complication...

[jonadab]

> I really like Debian, and I'd prefer not to wait a couple years for the
> next release. :-)

Umm, I thought the primary reason to like Debian Stable was if you didn't *mind* going several years between releases and didn't *want* to upgrade very often, where "very often" is defined as "while any of the software on your computer is still recent enough that reciting the version numbers doesn't cause people to wince in pain".

If you don't want to wait even two years for a release, perhaps you should look into some distro besides Debian Stable.

Re:One complication...

[steffl]

yes, _now_ stable is pretty much as new as unstable but that's like being happy having broken watch - they are right twice a day:-) The unstable is new every few years and there's no reason to believe it's going to be different this time.

If we see debian being released every 6 months to a year then perhaps stable might be an acceptable choice for desktop.

Re:One complication...

[ansible]

Well, if I wanted multiple years between re-installs, I'd probably use CentOS.

I think yearly releases would be reasonable for Debian. I was under the impression that most Debian developers wanted releases to occur at a faster rate than they currently are.

And if there's real need for a longer release cycle, you can always skip a release, and talk to people about maintaining the previous release for longer (assuming it did go to a yearly release cycle).

A release cycle of 6 months or less is hard for me to deal with on server systems.

Re:One complication...

[ArbitraryConstant]

"The GCC people are changing the API as the enormously complex C++ standard changes beneath them."

ABI != API

The ABI doesn't need to change to track API changes.

Re:One complication...

[cahiha]

Why, o why do they always make changing the C++ ABI such an effort?

Because that's the way C++ is designed: it has lots and lots of dependencies on data structure and vtable layouts. Why? Because it may save a few cycles in a few places that don't usually matter. The price you pay is that upgrades are a PITA.

Objective-C is a little better in this regard (but unfortunately has lots of other problems).

Re:One complication...

[Anonymous Coward]

You are wrong. GCC implements an ABI that is not covered by the C++ standard. When revisions are made to the ABI, GCC must change its implementation and everything breaks. When bugs are found in GCC's implementation of the ABI, they must be fixed and everything breaks. This is what the current ABI transition in Debian is caused by. It has nothing to do with updates to the C++ standard.

Re:Mmmmm, debian

[Anonymous Coward]

party like its 1999

Painless

[Anonymous Coward]

Yesterday I upgraded, answered two questions or so.

And today I boot my system, and all of the sudden I see Xorg in the process list, I completely forgot I switched!

Even tough the packages have common roots, I still think it's impressive, the way it should be.

Go Debian ;)

Is sid testing now?

[eneville]

It's about time Sid gave me something interesting. So whats unstable now?

Re:Is sid testing now?

[Anonymous Coward]

Sid is always unstable. It's where the new things start so eventually X.org will move up to testing then stable (but we'll all likely be dead before it hits stable).

Re:Is sid testing now?

[mattyrobinson69]

no. sarge is stable, etch is testing.

the version names are all from toy story, and sid is the kid that always broke the toys - therefore, sid will always be unstable.

packages from unstable trickle down into testing, which eventually get released all in one go to stable (like sarge did recently).

Re:Is sid testing now?

[Narchie Troll]

Sid is always unstable. The new testing codename is Etch.

*blink* *blink*

[WWWWolf]

Yesterday, I was having headaches updating something because Debian was again in motion and not all libjack packages had been recompiled to 0.100 yet. Among other things, libsdl1.2-dev was somehow suffering from this. I wanted to upgrade that package, but it depended on something called libglu1-xorg-dev. At which point I got worried...

apt-get search shows "xserver-xorg".

My first reaction was along the lines of "Well, as they might say, the End is Nigh" and the second thought was "wonder if anyone has a migration guide?"

Thanks for answering the second bit, I was already wondering why Slashdot hasn't noted this. I mean, I'm guessing I'm getting old if I find out the cool stuff before it gets posted =)

Re:*blink* *blink*

[Anonymous Coward]

But I thought "Debian unstable is more stable than most distros".

Oh wait, that's just crap propoganda only the True Believers buy into...

Re:*blink* *blink*

[WWWWolf]

But I thought "Debian unstable is more stable than most distros".
Oh wait, that's just crap propoganda only the True Believers buy into...

It is stable if you don't do crazy stuff like "apt-get dist-upgrade in a cronjob". =) The idea is to only upgrade when things don't look too broken.

Right now, if I say "apt-get install jackd", it says tons of packages are going to get nuked. Should I go ahead? No, the old versions of the proggies work. Will I go ahead? As soon as things get resolved.

Debian Unstable is fine if you use it like I do - when you need a new version of something, install it, and don't try to keep everything up-to-date all the time. And upgrade things if you can.

Re:*blink* *blink*

[dahlek]

Praise the Maker, so I'm not the only one? GAIM is having issues too...

It shocked me at first - I haven't been using Debian all that long compared to my total Linux life - the reason I switched was the nightmares associated with installing packages such as transcode in Red Hat (before they switched to apt), or even in Mandrake using urpmi (trust me, urpmi is no apt!) So when these things complained about installing, I felt like I stepped back in time several years, ready to pull out a pad and pencil and hunt down all of the silly depedencies...

dahlek

Re:*blink* *blink*

[be-fan]

LOL. I got bit by the same thing last night. THe libglu1-xorg thing is pissing me off, though, because gdm, startx, etc, depend on one version, while xine depends on another. I can't have them both isntalled simultaniously...

Re:*blink* *blink*

[be-fan]

PS> I don't suppose you know why GNOME is completely fubared in sid, do you? Somethinga bout libaspell15 not being installable?

Re:*blink* *blink*

[bcmm]

Migration guide:

I don't know what crap the distro has thrown in, but if the package manager isn't forcing things to break it goes like this:

# cp XF86Config-4 xorg.conf

Re:*blink* *blink*

[Rysc]

WTF?! I get the same Llama message by grepping mem. What causes that?

Re:*blink* *blink*

[bcmm]

You're just grepping the memory.

"Llama" first got loaded into RAM by your browser when you loaded my sig; then again when you executed the command.

In my case, there were also some weird ones. All sorts of stuff is in your computer's memory, stuff that would never go on the disks. If you have any P2P software, you will get usernames and filenames from other users. I tried it again just now, and the first result:

WTF?! I get the same Llama message by grepping mem. What causes that?m

Later on, I see the HTML source of that /. page, then the plain text that's clearly been through the HTML parser, then some old posts I made on another site weeks ago (why are they in memory? Presumably to do with Konqueror's autocompletion, but I haven't been to that site this session...).

It's all weird. There's enough stuff there that even a word like "Llama" will come up somewhere.

BTW, if you want to avoid getting modded down, don't use your karma bonus on offtopic posts. It makes the mods more likely to notice.

Re:*blink* *blink*

[bcmm]

BTW, any idea WTF this means, from my machine's memory?

uninstallDeleteMappings=Desea eliminar sus asignaciones de gestos?\n\nSus asignaciones se guardan en un fichero llamado 'mousegestures.rdf' en el directorio\nde su perfil. Mantenerlo no afectar\u00E1 a su sistema, pero permite a Gestos de rat\u00F3n \nusar sus asignaciones si los reinstala.

Probably to do with a Firefox XPI extension? (I don't know why I just said I'm using Konqueror, that was totaly wrong...)

How is support for radeon?

[Zweideutig]

I am running Debian (PPC) on my Mac Mini which has a 32 MB ATI Radeon video (with DVI output.) If I switch to X.org (which I am using with Slackware on my laptops,) is the support of my radeon going to be enhanced, or is this just about the license?

Re:How is support for radeon?

[demon]

Perhaps he likes the licensing, or the flexibility better? Or he's just a Linux diehard? Why not? I run Linux on my G3 Pismo - you can like the hardware and not be a fan of the OS, you know.

Re:How is support for radeon?

[Anonymous Coward]

Isn't Linus running Linux on a new G5 Mac? heh So am I, go figure. Why? Well, because I just like Linux, plain and simple. Need any other reason?

Re:How is support for radeon?

[Anonymous Coward]

I have switched on my ibook G4 (same graphic card as mac mini). 3D performance has much increased, suspend-to-ram works while DRI is enabled and I can get mirroring on VGA-out with DRI enabled thanks to MergedFB. So only good things. I only had to uninstall gedit.

Re:How is support for radeon?

[laffer1]

Well i don't know about Mac machines (i have one but its os x), but both my ati cards are VERY broken with xorg. Short answer.. any recent ati radeon card will not be accelerated with 3d at all and little with 2d (if any). There's a reason linux users on pcs try to get the awful ati binary driver to work. I'm effected badly because i happen to use FreeBSD so i'm in the same boat you're in.. no binary driver.

Every release of xorg has brought in more bugs and now my firegl card actually freezes the machine with 6.82 xorg. (its a radeon 8800 chipset) My radeon 9600 xt all in wonder isn't even detected automatically, and i've tried to get them to add the pci id.. they refuse. On the up side, the recent version seems to work well with windowmaker .91 and gnome 2.10 (i dont use them together)

The only other "advantage" is the font rendering system seems to be rather good in xorg. They have done some work in that area.

My opinion is that xFree86 is more stable and xorg is bleeding edge. Most BSD and linux distors have switched or are in the process of it though. If you don't come on board, you'll have compatibility issues down the road. I don't care about the license issue, but i do care about the software working.

Re:How is support for radeon?

[Zweideutig]

I have run FreeBSD on the desktop in the past. Now I run it only on servers. But besides my Mac Mini I have an x86 desktop (also running Debian,) albeit it has an nvidia (32 MB) card in it. The nvidia drivers were very easy to get running with Debian. GL-aware applications are provided with much better performance than the Mac Mini's Radeon 32 MB video. I suggest getting an nvidia card for your FreeBSD machine (does that run on FreeBSD with linux compat?)

Re:How is support for radeon?

[laffer1]

Actually nvidia has binary drivers for freebsd. I've been seriously considering purchasing one of their older chipsets (5500 or so). I figure its probably supported ok with the binary drivers. I do have linux compatibility enabled using the redhat 9 libraries.

heh, sid

[tehshen]

Woody: Reach for the X.org!
Sid Phillips: Huh?
Woody: This system ain't big enough for the two of us!
Sid Phillips: What?
Woody: Somebody's poisoned the XFree86!
Sid Phillips: It's busted.
Woody: Who are you calling busted, Buster?
Sid Phillips: Huh?

(Toy story)

Re:heh, sid

[Anonymous Coward]

Time to step away from your computer and get out of the house, sonny.

Comparisons?

[MindNumbingOblivion]

I realize I'm about to open a potential can of worms, but I really must know. I'm not that experienced with X, other than using GNOME or KDE. What are the pros and cons between XFree86 and X.Org? I think most of the boxen I've used were XFree86 based, and I am uncertain whether I have ever used one based on X.Org.

Re:Comparisons?

[stevey]

The big pro is since the licensing change almost all Linux vendors have moved to X.org.

That means there's more momentum behind it, and a lot of work will be happening on the new codebase - in a more open way.

Technically, right now, there are some changes between the two but nothing major unless you're using one of the cards for which the driver has been updated.

Re:Comparisons?

[Anonymous Coward]

For example translucent windows

Re:Comparisons?

[Homology]

What are the pros and cons between XFree86 and X.Org?

XFree86 changed their license last year, and this is the reason several *BSD and Linux distributions changed to X.Org. Xorg is based upon the latest unencumbered Free (just before XFree86 4.4), and developed from there.

Most users won't see much difference, yet, but XFree86 alienated many (most?) of their developers .

OpenBSD care more about free licenses than most, and they where less than pleased with the XFree86 license change; enough to include it in their release song

Re:Comparisons?

[Homology]

You asked about the difference as a desktop user between XFree86 and X.Org, and you got modded flamebait by some clueless moderator. How ironic that your sig says "#define CLUE 0".

Re:Comparisons?

[Anonymous Coward]

Basically, X.Org is "the new XFree86." XFree86's core team had its collective head up its ass, and all their best developers jumped ship.

X.Org was an organization that for a time handled the official releases of the X11R6 reference implementation. Some of the ex-XFree86 developers got together with the X.Org people, and re-launched X.Org as a group for working on XFree86. So the new XOrg server was originally based on XFree86 4.4-rc2 or some such.

Since then they have introduced extensions that people were TRYING to get into XFree86 for awhile, but the XFree86 were too busy keeping their head in the sand to accept them. This means stuff like DAMAGE and COMPOSITE extensions, as well as improvements to RENDER. This eventually leads to cool stuff like translucent windows and more efficient drawing.

There are some fundemental differences between them, sure, but are they really all that different? The answer is no. They both implement X. One of them has better drivers and some extra extensions, but in day to day operations, they're not different. I have a Linux box that runs XFree86 4.3 and an OpenBSD box that runs Xorg 6.8.2 and I can hardly tell the difference between them for most GUI activities. If I had, say, a commercial Unix box with a non-XFree86-based server, I probably wouldn't notice much difference either, provided it had the same programs.

Re:Comparisons?

[MindNumbingOblivion]

::chortle:: My first ever Flamebait mod (IIRC). Also my first ever positive mod Flamebait. Someone with mod points have mercy on me?

Re:Comparisons?

[Anonymous Coward]

The XFree86 group essentially became bogged down, and no longer open to new ideas which caused a lot of developer frustration. Then they changed the XFree86 license to add some extra clauses requiring distributions to output messages acknowledging xfree86 - not a big deal, but it was the final straw.

A fork of the code was taken to Xorg by a bunch of former xfree86 people. Both xfree86 and xorg now provide X implementations, but the xorg team are definitely working harder and distributions overwhelmingly favour it. I expect the xfree86 organisation to be effectively dead within 2 years.

xorg actually provides two versions of x:
* a "monolithic" bundle
* a "modular" bundle

One of the major problems with X in the past was that it was a huge amount of software, and it was always distributed as one piece. That meant releases were slow - not a good thing in the fast-paced graphics world. When a new driver was written, it wasn't available to users until the next full X release. From a developer point of view, the monolithic structure was bad, too, as it made it hard for new developers to learn just one piece at a time.

xorg's monolithic server is basically the same as the old xfree86 distribution, but with some fixes and a few new features.

xorg's modular server basically breaks the existing code into half a dozen separate packages (that's not as simple as it sounds!). Each piece can then be released on its own dev schedule. In particular, the "drivers" package can be updated much more frequently to provide users with drivers soon after they have been finished. The modular server is definitely the future direction.

AFAIK, most linux distros (redhat, suse, etc) are currently include the monolithic xorg distro; future releases of those will need to move to the modular structure.

However Ubuntu 05.04 - and now Debian Sid - are using the modular server. All good news.

Re:Comparisons?

[Anonymous Coward]

Regarding the modular Xorg, the reason no one uses it is that it hasn't been released yet. 6.8 is the current Xorg release, and is a monolithic tree similar to that of XFree86. Ubuntu 5.04 and SID uses that version (not the modular tree), as do most other distros.

6.9 and 7.0 will be released simultaneously later this year - 6.9 will be the next release of the monolithic tree, and 7.0 will be the first release of the modular tree, using basically the same code. The former is just there for transitioning, and will eventually die off.

Re:Comparisons?

[strider44]

Also there's been new work on the composite extension, hardware acceleration and a modular setup (to be released Sept 30).

Etch or Sid?

[phrostie]

cool news, but it doesn't seem to be in Etch just yet.

Re:Etch or Sid?

[MasterOfMagic]

After all of the package breakage is sorted out and it's been at least 14 days, then these packages will find their way into testing ('etch') if there are no critical bugs. You can check the status of this in the "excuses file" located on Debian's FTP site.

*mumble*

[Simon Kongshoj]

....and on the same day I finally switched to Ubuntu. First time I read /. after installing Ubuntu, I see this! Typical. :-)

Re:*mumble*

[EzInKy]

...and on the same day I finally switched to Ubuntu. First time I read /. after installing Ubuntu, I see this! Typical. :-)

I moved my g/f to Kubuntu after she lost KDE on her Debian unstable machine with an upgrade the other day. I'll probably stick to Gentoo myself but I must say so far it does look like the perfect combo of being fairly stable but up to date.

Re:*mumble*

[Anonymous Coward]

Did you install warty or hoary? I have a procedure to upgrade warty --> etch in the works. I haven't done a hoary --> etch upgrade yet, because of Xorg. Now I should be able to move forward and have my HOWTO posted in the near future.

YES!!! X.Org!

[DarkYoshi]

Okay, look at how nice the new visual effects for the desktop are on X.Org! Just wait for me to log out...

What? Why do I have to log out? Because it takes far too much of the CPU power I have.

Waits 30 more seconds for Debian to start...

THERE! LOOK! IT'S REAL TIME TRANSPARENCY! WOW! ISN'T IT AWESOME?!?!

Me: No. No, it isn't. In fact, I can't see a difference between KDE 3.4.1 with X.Org and KDE 3.1 with XFree86. ^^^ That was an exaggerated dialogue between my friend and I when he was showing me some useless visual effects on Gentoo with X.Org.

Re:YES!!! X.Org!

[ZorinLynx]

>486-DX4 100mhz
>28MB RAM
>1.7GB HD
>1MB SVGA

With a system like that, I'm not surprised things are a bit slow. Join this decade, dude. Even if you're poor, a low end Pentium II system you can probably get for $50 will trounce that and you'll be much happier. }:)

-Z

Re:YES!!! X.Org!

[DarkYoshi]

No, those specs are just on my old box, which I play Warcraft II on once in a while. My new box has a Radeon 9600, so no problems there.

Debian Sid Moves to X.Org

[Anonymous Coward]

Note to author: the usage of "moves" is ambiguous in title. It is unclear, from context alone, if it is being used as a transitive or intransitive verb.

USE KOMPRESSOR GRAMMATIK!

1863 just telegraphed.

[kinzillah]

They want their petrol based internal combustion engine back...

X.Org vs. XFree86?

[findrac]

X.Org supports accellerated dualhead with driver radeon(4) with pseudo-xinerama (mergedfb). XFree86, forget about it. And with just single head, using same driver.. Enemy Territory is now playable, was not in XFree86 and forced r200 ATi users to ATi propietary Closed Source. I'd say this is a major improvement. Forget about Composite extension, it's still EXPERIMENTAL in 6.8.2.

Re:X.Org vs. XFree86?

[Anonymous Coward]

> ... forget about it.

the mafia reads slashdot now too?

Re:X.Org vs. XFree86?

[Anonymous Coward]

the mafia reads slashdot now too?

Just look at where you get modded.

nvidia drivers?

[WWWWolf]

So... anyone yet tried how well this works with the NVIDIA drivers (specifically, using Debian's own nvidia packages - nvidia-glx and nvidia-kernel-source through make-kpkg)?

Anyone tried yet? How's things?

Applications can be broken for all I care, but I need my OpenGL =)

Re:nvidia drivers?

[findrac]

nvidia-glx and other dependencies of that are still in Debian Experimental repository. So, they are done but not in Unstable just yet. Maybe after tonight?

Re:nvidia drivers?

[bioglaze]

I'm using it with drivers downloaded from NVIDIA and acceleration works fine.

Re:nvidia drivers?

[jascat]

I'm on my brand spankin' new debian install with xorg going and the latest nvidia drivers. The only things I had to change in the transition from XFree86 to X.org was to change the driver for the keyboard from "Keyboard" to "kbd". Everything else was standard with the nvidia install.

Re:nvidia drivers?

[Anonymous Coward]

Same here, everything's workin' ok.

Re:nvidia drivers?

[Hal XP]

The version already in unstable (1.0.7174-3) works fine (or no worse) with the xorg packages. There's actually even a warning attached to the experimental version (1.0.7667-1). The latest nvidia binary package supposedly does NOT support older (legacy) nvidia-based card like the TNT. Since all I have is a TNT-based card, I've decided to stick with 7174.

Re:nvidia drivers?

[WWWWolf]

Okay, so I followed a complete stranger's advice from slashdot: logged off, shut down gdm, did apt-get install xserver-xorg, fired up gdm, and after it loaded it up ponderously and slowly, all of my fears disappeared: *poof* here's my gdm again, now on a brand new X.Org server.

Hmm. No stuff broken, just a few weird new extensions I've heard about. So this is what the fuzz is all about. Not much different from XFree86, aside of the fact that this thing has a non-stupid name. =)

First time for a long time I'm using something else besides XFree86 on my own X11 desktop... I did try Metro-X ages ago but stopped when new XF86 worked again with the monitor. That was in nineteen... ninetyseven or thereabouts. And now I don't even feel any weird. =)

Re:nvidia drivers?

[Anonymous Coward]

It's not really better than before; things were better then.

Re:nvidia drivers?

[Serpent Mage]

just follow these steps after installing the debian nvidia-source package.

cd /usr/src
tar xvfz nvidia-source-version.tar.gz
module-assistant a-i nvidia-source

DONE! works like a charm on debian stable/testing/unstable

Re:nvidia drivers?

[spankfish]

well this explains a thing or two.

I'm stuck with a TNT based card myself. Even with the old drivers, my entire machine would randomly hang for no apparent reason, if X was using the "nvidia" (not nv) driver.

Utter crap

[ardor]

I have been using X.org for almost a year, and it works rock solid. It is MUCH faster than Xfree, and Debian still starts fairly quickly (X.org didn't lengthen the startup time at all).

As for the special effects: wrong, wrong, wrong. OSX shows how these effects can be useful. Also, the transition to a GL desktop will most likely be implemented in a new version of X.org which merges with Packard's work. A GL desktop actually helps the CPU by taking away the task of drawing stuff from it and having the GPU do it, which is the logical thing to do.

But I know, anything else than crude blitting is l4m3, hard core spartan X11 is l33t. Yeah....

Re:Utter crap

[MBCook]

I've been on OS X for a few months and I agree with you about the special effects. Before that I thought those kind of effects were interesting but mostly useless.

But on OS X they are implemented nice. The way things zoom off the screen to show you your desktop or the slight transparency of sheets asking you questions are both nice. And the genie effect when you minimize a window or restore it is nice too and directs your eye to where it is going. Apple has done a great job.

Now that's not to say it can't be done bad. The screenshots of the latest beta of longhorn worry me. The way the titlebar area is mostly transparent was simple distracting looking. That was something that I would turn off almost instantly. I don't know if that was a showcase (not bad), or they intended to keep it that way (ug), but it was a problem.

Re:Utter crap

[alienw]

How about just moving a window around? You get nice, smooth motion, without seeing stuff being redrawn and such. Compared to OSX, both Linux and Windows are in the stone ages.

Re:Utter crap

[Renegrade]

A GL desktop actually helps the CPU by taking away the task of drawing stuff from it and having the GPU do it, which is the logical thing to do.

I dunno about that, OpenGL is rather CPU bound. Much of the OpenGL pipeline is still done by the processor, and the primitives for OpenGL are often optimized for fully 3D rendering, which is more than a little unoptimized for 2D blitting. glTranslate3f ?

A 2D-specific blitter is a simple matter of setting up a few registers and letting it happen. A 3D operation in OpenGL has to be converted to native formats, be processed through the fragment pipeline, and then multiplied through several matrix operations before anything happens. While a modern T&L card does much of the more costly things involved in this, there's still all the necessary conversion and setup which is done by the processor.

Some of these OpenGL operations may require serialization, which might even involve a hidden busy loop, depending on how defective the operating system/drivers is/are.

While much of this may be relatively trivial on a modern, ghz-scale system, anything that is taking away from my BOINC credits is teh devil, I say! (Plus one day, you might end up stuck on a lesser machine, waiting for the parts store to open...)

(NB. most of this work is required for a 3D application, so OpenGL operates efficiently when playing Quake IV, as all of these operations would be necessary in any system, save perhaps the type conversion.)

Re:Utter crap

[MBCook]

Quite true. But that's the kind of thing you tend to forget about. That's only something I'd only mention on Windows because I'd notice the problem and it'd bug me. It some ways it's like mentioning that clicking on icons opens programs on OS X, that's just the way that it should be. It's 2005, and computers can render amazing things (like that Half Life 2 Machinima). If they can do that, they should be able to move windows smoothly.

Re:Utter crap

[alienw]

It's not difficult to make windows move smoothly and to have cool effects. It IS difficult to efficiently integrate all this stuff into a 20-year-old window system while remaining compatible with many thousands of programs written for it and hundreds of different video chipsets. Apple doesn't have this problem because they could afford to scrap their old OS and redo everything from scratch. Neither Microsoft nor Linux can afford this luxury.

Re:Utter crap

[ardor]

I dunno about that, OpenGL is rather CPU bound. Much of the OpenGL pipeline is still done by the processor, and the primitives for OpenGL are often optimized for fully 3D rendering, which is more than a little unoptimized for 2D blitting. glTranslate3f ?

A 2D-specific blitter is a simple matter of setting up a few registers and letting it happen. A 3D operation in OpenGL has to be converted to native formats, be processed through the fragment pipeline, and then multiplied through several matrix operations before anything happens. While a modern T&L card does much of the more costly things involved in this, there's still all the necessary conversion and setup which is done by the processor.

You should not use glTranslate3f at all with 2D.
Instead, use dynamic vertex buffer objects. Similarly, use pixel buffer objects for the textures (the window contents). And no, nowadays almost nothing is done by the CPU. Just commands are sent, and in this case, vertex data is transmitted. But transfer is mandatory anyway.
Ever seen a GL GUI? Those things are *FAST*.

With a 2D blitter, you have to perform conversions too (32->16 bit for instance). The CPU has to do setup for a 2D blitter, too.

Some of these OpenGL operations may require serialization, which might even involve a hidden busy loop, depending on how defective the operating system/drivers is/are.

No, you are complicating it. As I said, GL GUIs are real and blazing fast. There are tons of GL GUIs for SDL, and ClanLib renders *everything* with GL (yes, the 2D stuff too).

While much of this may be relatively trivial on a modern, ghz-scale system, anything that is taking away from my BOINC credits is teh devil, I say! (Plus one day, you might end up stuck on a lesser machine, waiting for the parts store to open...)

Yes, the lesser machine is a problem. However, 3D support is not. Today, EVERY graphics chip set supports basic 3D rasterization and T&L. In case where there is no support available, simply fall back to traditional methods.

Re:Utter crap

[nathanh]

How about just moving a window around? You get nice, smooth motion, without seeing stuff being redrawn and such. Compared to OSX, both Linux and Windows are in the stone ages.

You can get the "nice smooth motion, without seeing stuff being redrawn" on Linux as well. Just install xserver-xorg, enable the Composite and Damage extensions, and run xcompmgr in your login script. Voila, smooth motion, no redraws.

Some of the distros have already packaged this up, so these "difficult" instructions are just a means of explanation.

Re:Utter crap

[Anonymous Coward]

Apple doesn't have this problem because they could afford to scrap their old OS and redo everything from scratch.

Hang on - correct me if I'm wrong, but isn't OSX heavily based on BSD? Wouldn't that make it NOT rebuilt from scratch?

Wouldn't that make you a zealot and a troll?

Shouldn't you go play with the other trolls?

Under the hood ...

[Ezdaloth]

with all the good work on tranparancy, and nice effects, i'm still missing one big under-the-hood change: use something like DRM/DRI for all 2d graphics too! (similar to directfb, windows, maxosX, etc)

Currently there are hundreds of context-switches between the x-server and your applications just to draw things. Windows doens't have that (since w2k anyways) and it increased windows' graphics performance quite some bit. MacOS has quartz extreme 2d now, and it increased their performance. This really slows things down. :-(

I think before more fancy effects are added that only make the whole thing slower are added, these under-the-hood optimizations should be done!

Re:Under the hood ...

[Anonymous Coward]

It's allready in X.Org CVS, new EXA accelleration. Working in driver sis(4) and soon to be in radeon(4). Let's just hope EXA for radeon(4) gets into X.Org 6.9/7.0. It's mentioned here: http://xorg.freedesktop.org/wiki/ChangesSince68

Re:Under the hood ...

[osho_gg]

I am not sure that you are familiar with the work going on now for creating new acceleration for X.org.

http://slashdot.org/article.pl?sid=05/06/28/124525 8&tid=104&tid=130

This aims to do exactly what you are talking about and some more (as I understand it).

Osho

Re:Under the hood ...

[Ezdaloth]

As far as i understand it, EXA doesn't make Xlib calls go to the kernel instead of X. It is just a more efficient accelleration framework for X internally.

DRI/DRM makes going through XFree86 for each line, block or texture un-necessary. These functions become a systemcall, which reduces the number of (expensive) context switches by a half.

Re:Under the hood ...

[be-fan]

Windows and DirectFB don't do anything like that right now, only Quartz 2D "Extreme" does.

Re:Under the hood ...

[be-fan]

Except that's not what DRM/DRI does, nor what XFree86 does. When you call XDrawLine(), it just queues some things in a buffer and returns. When the buffer is full, there is one context switch to deliver all the buffered commands to the X server. This is actually what Windows does too, btw, except instead of having an X server, it has a "Win32 server" in kernel mode.

DRM/DRI work similarly to X (and similarly to how OpenGL works on Windows). When you draw a primitive, it puts some things in a command buffer. When the buffer is full, an ioctl() on the graphics card DMAs the command buffer to the GPU, which then draws all the lines, triangles, etc.

Doing a system call for each line would be painfully slow, since system calls cost you a lot of cycles. Even if you had the graphics card mapped directly into every process, so they could bang registers directly (which would be dangerous, but this is hypothetical), you'd still want to batch the primitives into a buffer, because small writes over the AGP bus are very slow. Now, once you're batching calls anyway, doing a kernel call to upload the buffer versus doing a context switch to upload the buffer doesn't make a whole lot of difference. Even if the latter is several times slower, you're not executing buffer flushes all that often anyway.

Re:Under the hood ...

[softends]

Use enlightenment. No bloat (fast) and you don't need all those slow extensions for dropshadows and (fake) transparency. And it's beautiful.

Re:Under the hood ...

[jrockway]

Why not have processes append to the buffer (which is a shared memory region) and have the video card poll this buffer every n milliseconds (say, 60 times a second if the refresh rate is 60Hz). Then there would be no context switch, just writes to memory (which is relatively speedy).

I don't know if this is effective or possible, though :)

Re:Under the hood ...

[Ezdaloth]

Of course you're right. I know that's what's really going on. But that doesn't make my argumentation less true: running things "directly" via system calls is a lot faster then going via X. Why do you think DRI/DRM is a lot faster than 'indirect' opengl?!

It becomes an issue as soon as your graphics card isn't the bottleneck in drawing things, but when context-switching to XFree86 draw things is. Any modern card card can draw triangles and lines so insanely fast that extra context-switching *will* slow it down.

If you don't beleive me, check the numerous articles about why w2k has this in the kernel (as opposed to winnt3.5/winnt4), why macosX now has quartx extreme 2d, why dri/drm is so much faster. Doing this avoids extra overhead, and on anything but an s3 trio32 or similar you'll notice the improvement.

Re:Under the hood ...

[Ezdaloth]

"To execute a specific graphics operation driver will access the memory mapped command to the card's acceleration engine. is done entirely from user space."

^^ Quote from page 4 of the DirectFB architecture overview. Sounds to me like directfb does pretty much what i said. (Except even more direct, apparently :P)

"It's not necessarily the X people who object to kernel mode video drivers - it's the people who decide what goes into the kernel. While they make the driver run faster, it's at the expense of stability. When they put the graphics drivers into the NT4 kernel, it allowed user-level code to crash the OS by using invalid parameters to API calls. It took MS a while to get the bounds checking right. But this is off-topic, so I'll leave it here."

^^^ So winnt has graphics drivers in the kernel since nt4. Can't find another quote handy, but iirc since w2k graphics operations even go directly to this kernel driver, instead of via the win32 subsystem.

Re:Under the hood ...

[be-fan]

Of course you're right. I know that's what's really going on. But that doesn't make my argumentation less true: running things "directly" via system calls is a lot faster then going via X.

Yes, it's strictly faster. The question is, how much faster is it, and where is the bottleneck? A context switch is on the order of a few thousand cycles, while a system call is on the order of a few hundred cycles. Meanwhile, uploading a 100KB DMA buffer over the PCI-Express bus is on the order of 50,000 cycles. Even if you reduce the context-switch overhead to zero, you're still only improving performance by around 6%.

Why do you think DRI/DRM is a lot faster than 'indirect' opengl?!

Because indirect OpenGL is not hardware accelerated!

If you don't beleive me, check the numerous articles about why w2k has this in the kernel (as opposed to winnt3.5/winnt4)

Actually, NT4 put graphics in the kernel. Of course, Windows NT 3.x also had a much more micro-kernel design, so its hard to say where the performance improvement came from.

why macosX now has quartx extreme 2d

MacOS X has Quartz Extreme 2D because it allows hardware acceleration of 2D, not because it reduces client/server overhead.

why dri/drm is so much faster.

Because it's accelerated...

I don't think you really understand what you're talking about. Having done some programming on the subject myself, I can say that the bottlenecks in X aren't really where people think they are. The top bottlenecks in X GUIs like KDE and GNOME are:

1) Synchronization. Konqueror on my 2GHz P4 can relayout and redraw Slashdot at like 20fps. Should be enough for smooth resizing, right? Wrong! There is no synchornization between window manager and client in X. The window manager would redraw the window frame a hundred times per second, and not let the contents catch up. Once you fix that synchronization problem (eg: via the SYNC counter spec), it becomes very smooth. The truth of graphics is that no matter how fast it is, it will never look "smooth" without synchronization. X doesn't have support, by default, for that synchronization.

2) Text layout. Pango (what GNOME uses for text layout) is glacially slow. That's why resizing gedit windows is slow, not because X can't draw things fast enough.

3) Text compositing. Only a few drivers properly accelerate XRender. Other drivers have a software compositing fallback, which is glacially slow because it requires the CPU to read/write to video memory over the AGP/PCI-E bus.

Re:Under the hood ...

[be-fan]

It doesn't really matter. It's the buffer upload to the graphics card that costs tens of thousands to hundreds of thousands of clock cycles. The context switch only cost a few thousand clock cycles, so unless you're scenes are very simple (ie: your buffers are tens of kilobytes instead of hundreds of kilobytes or megabytes), then its not the context-switch that's the bottleneck. Of course, if your scenes are very simple, it doesn't really matter how fast your graphics are!

Re:Under the hood ...

[be-fan]

You said that X should use something like the DRI/DRM for all graphics ops, like Win2k, and DirectFB and Quartz 2D Extreme do. DRI/DRM is the OpenGL (3D) driver API. It doesn't just mean "kernel-mode graphics driver". Win2K and DirectFB don't use 3D driver APIs to do 2D operations. Quartz 2D Extreme does, and Microsoft's Avalon will.

PS: DirectFB is a very dated architecture, as is DirectX. Modern graphics cards don't like apps to directly touch video memory or directly bang registers. Its touch to synchronize direct access with the GPU. They are built for the OpenGL ICD model, which depends on a protected kernel driver uploading command packets to the hardware. Indeed, "direct access" is going away in DX10, which will debut with Avalon.

Re:Under the hood ...

[spitzak]

You still need synchronization of some sort so that the calling program can know when it can overwrite or free the buffer. The way to do this is effectively what X (and Windows) does, which is to copy/move the data over to the other process in an effectively synchronous block operation.

The other end can interpret the data as you said and then free/reuse the memory. Such a polled operation may be very good on modern systems as it would get rid of tearing simply without using double buffering.

Re:Under the hood ...

[Ezdaloth]

Yes, it's strictly faster. The question is, how much faster is it, and where is the bottleneck? A context switch is on the order of a few thousand cycles, while a system call is on the order of a few hundred cycles. Meanwhile, uploading a 100KB DMA buffer over the PCI-Express bus is on the order of 50,000 cycles. Even if you reduce the context-switch overhead to zero, you're still only improving performance by around 6%.

I think what you're forgetting is, during these 50,000 cycles your app doesn't have to wait. Last time i checked DMA'ing was done mainly independent of the CPU, so your app can keep doing things in the mean time. (at least during the bulk of the 50,000 cycles) Also it's not one context-switch but two: one to X and one from X. Now you see a different picture: a couple of hundred cycles vs several thousand cycles. (ignoring overhead for setting up a DMA transfer ...) That's what i was trying to explain to you in the last post.

And your part about synchronization .. please don't tell me you want to add another context-switch to X, just to synchronize every now and then?! (ok, with rendering via X you're not adding one .. but you are in the case of apps using direct rendering) This is the kind of stuff why X needs to do many more things 'direct' via system calls. This synchronization can be implemented way more efficient with kernel primitives then with messages being sent back and forth.

Re:Under the hood ...

[be-fan]

I think what you're forgetting is, during these 50,000 cycles your app doesn't have to wait. Last time i checked DMA'ing was done mainly independent of the CPU, so your app can keep doing things in the mean time.

It doesn't make a difference to your graphics performance. Having those 50,000 cycles free only helps you if you're CPU-bound. When drawing complex graphics, you're rarely CPU bound. In any case, even if you reduce the setup and context switch overhead to 0 cycles (and you do an upload say 120 times per second --- twice per frame), you're talking about a fraction of a percent of overall CPU time.

Also it's not one context-switch but two: one to X and one from X.

I took that into account. A single context switch is on the order of 1000 cycles, two is on the order of a "few thousand".

Now you see a different picture: a couple of hundred cycles vs several thousand cycles.

And it's all completely overshadowed by the real bottleneck, drawing things on the graphics card!

And your part about synchronization .. please don't tell me you want to add another context-switch to X, just to synchronize every now and then?!

The context-switch overhead is nothing. If you resize at 30 fps (I have it rate-limited because anything faster is wasted), you have roughly six context switches per frame (between the window manager, the client, and the X server). At 1000 cycles apiece, that's 180,000 cycles per second, which is noise.

This is the kind of stuff why X needs to do many more things 'direct' via system calls. This synchronization can be implemented way more efficient with kernel primitives then with messages being sent back and forth.

Let's see. Your tradeoff is less than a 1% performance gain for putting a million lines of code into the kernel. Brilliant!

Re:Under the hood ...

[Ezdaloth]

And it's all completely overshadowed by the real bottleneck, drawing things on the graphics card!

This is a bullshit argument, i have quite a quick radeon card. You're not telling me that card can't draw a browser window fast enough. Though your argumentation sounds allright for the rest, this can't be correct.

Let's see. Your tradeoff is less than a 1% performance gain for putting a million lines of code into the kernel. Brilliant!

In your last post that was still 6%. Check your numbers. And you keep compare those 1000 cycles to some bigger number, probably the total number of cycles you CPU does each second. Stop that, compare it to the version without the context switch please! If such a change can optimize a call to draw some lines (a buffer full) from several thousand to several hunderd, that's a *huge* improvement. Several such improvements can add up quickly and will mage the whole of X feel less sluggish.

For the rest i never suggested putting a million lines of code in the kernel! BTW, what difference would it make anyways? XFree86 runs with elevated privileges already, and can crash your system anytime it wants to.

What i'd suggest is to put a simple graphics driver into the kernel, videomemory management and maybe some synchronisation between apps in there. In the worst case that are 5000 lines, plus some 10000 for each graphics driver. Apps could draw by themselves, and X and the windowmanager etc can combine each app's buffer onto the screen.

Re:Under the hood ...

[be-fan]

This is a bullshit argument, i have quite a quick radeon card. You're not telling me that card can't draw a browser window fast enough. Though your argumentation sounds allright for the rest, this can't be correct.

This statement has nothing to do with what I said. I didn't say that the bottleneck in drawing your browser window is the graphics card, I said the bottleneck in the overall X -> kernel -> graphics card communication process is the AGP/PCI-E bus. The reason your browser window doesn't draw fast enough is the reasons I mentioned earlier. I'll reiterate them, since you obviously didn't read my post very carefully:

1) Synchronization --- appearing fast is better than being fast and appearing slow. OS X is actually quite slow. But people think it has a very nice "feel" because everything is smooth, synchronized, and double-buffered. With your emphasis on saving a few irrelevent clock cycles here and there, you're completely missing the real things that make a GUI feel fast. Synchronized resize, double buffering --- all of those cost lots of cycles. But they're all absolutely necessary in making a UI feel fast.

2) Text compositing. The speed of your Radeon card doesn't really even come into play, because its barely even getting used! A major bottleneck in screen drawing is alpha-blending thousands of glyphs onto the screen for every character of text. On most cards, that alpha blending is not accelerated by the blending engine on your card. Instead, the CPU has to do a painfully slow read/modify/write for each pixel in the image. That's wicked slow.

3) Layout. Layout is the single biggest bottleneck in the whole chain. Every time you resize your window and you're left with a blank gray area where your content should be, do you think that area exists because X can't keep up? Hell no! It exists because the layout engine can't keep up!

In your last post that was still 6%. Check your numbers.

Learn to read. The 6% is how much time you'd save in the buffer flush process if the context swithch overhead was zero. The 1% is how much CPU time you'd save overall.

And you keep compare those 1000 cycles to some bigger number, probably the total number of cycles you CPU does each second. Stop that, compare it to the version without the context switch please!

What do I care about the version without context switches? I'm a programmer, all I care about is the bottom line. I don't care if task A is a thousand times faster if it only takes 1% of my CPU time to begin with. The key to designing a fast system is concentrating on the things that are slow. If text layout takes 30% of your time, and context switches eat up 1%, you'd be a moron to go to a lot of trouble optimizing the latter. Even if you could make it 1000 times faster, you'd gain nothing!

If such a change can optimize a call to draw some lines (a buffer full) from several thousand to several hunderd, that's a *huge* improvement. Several such improvements can add up quickly and will mage the whole of X feel less sluggish.

That just makes no sense mathematically. Why bother trying to make several minor things 10 times faster, just to gain 1% here and 1% there, when making one major thing even 2 times faster will gain you much more?

BTW, what difference would it make anyways? XFree86 runs with elevated privileges already, and can crash your system anytime it wants to.

X cannot crash your system if it goes down. It can delete all your files, but like any userspace process, it cannot crash the kernel.

What i'd suggest is to put a simple graphics driver into the kernel, videomemory management and maybe some synchronisation between apps in there. In the worst case that are 5000 lines, plus some 10000 for each graphics driver.

Hah! Have you ever written a graphics driver? Go read the DRI or Xgl mailing lists sometime. Mode setting alone is hundreds of kilobytes of code! Proper, generic video memo

Re:Under the hood ...

[Ezdaloth]

That just makes no sense mathematically. Why bother trying to make several minor things 10 times faster, just to gain 1% here and 1% there, when making one major thing even 2 times faster will gain you much more?

1% overall in 10 different places can still be 10%, but that's beside the argument here. I didn't say that you shouldn't do the other things, you should definitely optimize that big case too.

But i as a programmer tend to get the basic design right first; and when that works, i move on to fixing things that work on top of that. Then again, my half-finished projects aren't widely in use. :P

X cannot crash your system if it goes down. It can delete all your files, but like any userspace process, it cannot crash the kernel.

Sorry, but that isn't true. X runs at an elevated privilege to access IO ports etc. It can definitely crash your system. Guaranteed.

Hah! Have you ever written a graphics driver? Go read the DRI or Xgl mailing lists sometime. Mode setting alone is hundreds of kilobytes of code!

I haven't written written one, but i have modified some, since they *crashed* my system. And your number naming for the rest is kind of pointless, I didn't tell you to put a whole X in the kernel. That would indeed be kernel-bloat.

Anyways, i kind of through with this. I think you're exaggerating/misinterpreting some things, you think i am. We prolly both have some points of truth. Let's end it before it becomes a flamewar. Cheers!

Re:Under the hood ...

[be-fan]

1% overall in 10 different places can still be 10%, but that's beside the argument here. I didn't say that you shouldn't do the other things, you should definitely optimize that big case too.

But we're not talking about 10 different 1%'s, we're talking about this particular 1%. The cost of changing it is high, and the gain is only 1%. If they other 9 1%'s don't involve moving large amounts of code into the kernel, well, you can have those, but leave this particular 1% alone.

Sorry, but that isn't true. X runs at an elevated privilege to access IO ports etc. It can definitely crash your system. Guaranteed.

Good point. X can crash your system by issuing improper DMA requests to the graphics card. But my point still stands. There is a very limited part of X (the graphics driver) that can crash the kernel. However, in a kernel-mode graphics system, there is a much larger part (even something like reading configuration files) that can crash the system.

I haven't written written one, but i have modified some, since they *crashed* my system. And your number naming for the rest is kind of pointless, I didn't tell you to put a whole X in the kernel. That would indeed be kernel-bloat.

I didn't say to put the whole X in the kernel. I was just talking about the parts you were talking about --- managing video memory, managing windows, etc. If you want to eliminate context switches, those things need to go into the kernel. That's still tens of thousands of lines of code.

Re:gentoo leads

[Anonymous Coward]

Sure Gentoo switched a while ago, but everyone is still compiling it so no one is actually using it yet.

that x.org stuff is alright.

[Anonymous Coward]

I run debian _unstable_ (because IDGAF) and have had that xorg stuff running for quite some time now. I wouldn't say It's faster but it didn't bitch more then XFree86 during/after installation. As a matter of fact /etc/X11/xorg.conf and /etc/X11/XF86config-4 look exactly the same.

Re:wow

[Anonymous Coward]

Linus, RMS, ESR, Icaza ...

Re:gentoo leads

[makomk]

Sure Gentoo switched a while ago, but everyone is still compiling it so no one is actually using it yet.

Very funny. Actually, X.Org recompiles aren't too bad (and yes, Gentoo does use it by default, as does Mandrake Linux or whatever it's called these days). The real killer is stuff like KDE - multi-day compile times, anyone?

mirror?

[SkunkPussy]

server seems to be slashdotted and this doesn't get it yet (for me)... anyone got a mirror?

Re:mirror?

[Anonymous Coward]

Like every other slashdot story, it's mirrored at goddamn mirrordot.

CLICKY AND READY

Synaptics driver?

[adriantam]

I am using a notebook, so, anyone have experience using X.org with synaptics (i.e. the driver for touchpad in notebook)?
My XFree86 works very well with synaptics indeed.

Re:Synaptics driver?

[palmem]

I am running Gentoo with xorg

The touchpad on my Dell Inspiron5150 works OK
Sometimes it is unaccurate

Re:Synaptics driver?

[Anonymous Coward]

Works great in Ubuntu under X.org for me. Never had any problems with it.

Re:Synaptics driver?

[DrYokomohoyo]

The synaptics driver is well supported with xorg. I have an alps touchpad on my pavilion zv5000 and all its features are supported.

Re:Synaptics driver?

[Anonymous Coward]

I'm running Gentoo/X.org on an Asus laptop and the synaptics driver works great for me. I can even use some gestures on it to get middle and right mouse clicks without using the buttons. It also supports vertical and horizontal scrolling via the pad.

Congratulations Debian community

[Pecisk]

It seems like you have cracked your deadlock which was more or less Sarge release (of coarse lot of Debianists will claim that it was just how it was to be - and I partly agree with them). There are lot of things will change in Debian soon - as Mandrake and co are planning to weight in with creation of enteprise level distro based on it and lot of development which was held back after Sarge release is really happening now - and I excited to see my second favorite distro to move forward faster and faster.

Re:Congratulations Debian community

[Anonymous Coward]

as Mandrake and co are planning

It's not Mandrake [Mandrive of course] and co, but more Progeny and co.

Re:gentoo leads

[Willard B. Trophy]

And x.org CVS under Gentoo has VIA Unichrome support, so my Mini-ITX box is happy. I guess Debian stable will get it in 2009, or so ...

Smoothest major upgrade I've ever done

[Anonymous Coward]

I did the upgrade last week, and it's been no problem at all. I've had to hold back xbase-clients and xutils because they want to pull in libgluc2 (with the new C++ ABI), and I have software that uses the old stuff, but the vast majority of it is running X.org.

Runs real sweet, too.

No problems on a laptop or 4 desktops. Just use aptitude and hold back anything that causes conflicts.

Oh, and I didn't make any safety backups at all. Crazy me.

Broken Packages

[InfiniteWisdom]

Take a look at the jump in the number of release-critical bugs! Is this all related to X.org or is there some other major change in the works?

Re:Broken Packages

[xenocide2]

That would be the transition in the C++ ABI (ie a transition to gcc 4). That would be an excellent reason to keep with testing rather than unstable.

Re:Broken Packages

[ashridah]

You may also keep in mind that debian was in freeze for a while. It could just be newish packages rolling down the line that couldn't enter unstable before now.

This is probably secondary to the gcc 4.0 migration and X.org however. :)

ash

./ed

[Anonymous Coward]

This is the Mirror.dot version

Well, I think

[urbster1]

only one thing needs to be said: finally!

Full Article Text

[rsrsharma]

Debian Unstable gets X.org

Posted by Steve in the Debian section on Wed 13 Jul 2005 at 17:10

Debian has now made the transition to the X.org installation of the X11 Window system. If you're running sid/etch you should be able to upgrade now.

The transition had previously been on hold until Sarge was released - as it was judged too major a change to add to the release at the last minute.

Now Sarge is out Debian development continues and one of the most anticipated changes is upon us. (Other changes are also occurring such as the C++ ABI upgrade).

Before starting the upgrade to X.org it's important to do two things:

• Switch to a console as a paranoid safety measure. If something goes wrong, or X gets restarted you don't want to leave your upgrade in an inconsistent state.
• Take a backup of /etc/X11 in case you experience problems.

The backup can be something as simple as running:

cp -R /etc/X11 /etc/X11-old

The upgrade will attempt to automatically migrate your XFree86 configuration file to /etc/X11/xorg.conf, and in my case worked perfectly. Still better safe than sorry!

Once you've done those two things you should be ready to proceed. As always the first thing to do is update your list of available packages:

apt-get update

If you wish you can use aptitude instead, I know that I should promote that more.

With that out of the way the installation is started by running:

apt-get install xserver-xorg

This gave me the following output:

The following extra packages will be installed: libxau6 libxdmcp6 lsb-base x11-common xfree86-common xserver-common Suggested packages: configlet-frontends libglide2 Recommended packages: mdetect xresprobe The following packages will be REMOVED: xserver-xfree86 The following NEW packages will be installed: libxau6 libxdmcp6 lsb-base x11-common xserver-xorg The following packages will be upgraded: xfree86-common xserver-common 2 upgraded, 5 newly installed, 1 to remove and 14 not upgraded. Need to get 7437kB of archives.

As you can see the xserver-xfree86 package is scheduled for removal, as the two conflict.

After downloading the packages from the network you'll be asked which server you wish to run by default by debconf. Choose the xserver-org - as the other server will be removed.

That was literally all I had to do. There were several messages displayed about migrating the server's configuration which appeared to be completely successful:

xserver-xorg config warning: migrating xserver-xfree86 templates to xserver-xorg.

Other diagnostic messages also seemed to indicate the upgrade was occuring without any problems:

Adding system startup for /etc/init.d/x11-common ... /etc/rcS.d/S70x11-common -> ../init.d/x11-common update-rc.d: /etc/init.d/xfree86-common exists during rc.d purge (continuing) Removing any system startup links for /etc/init.d/xfree86-common ... /etc/rcS.d/S70xfree86-common

At this point the upgrade was complete, and the only thing left to do was to stop the currently running old installation of xserver-xfree86. The quick way to do this would be to simply reboot, although I wanted to do it manually to make sure it worked as expected.

I use the IceWM window manager with the gnome display manager handling the logins - so to stop X I ran:

/etc/init.d/gdm stop

This step will differ if you're using KDE, in which case you'll need to use "/etc/init.d/kdm stop". If you're using another login manager such as wdm,

Re:gentoo leads

[cpghost]

The real killer is stuff like KDE - multi-day compile times, anyone?

Same here under FreeBSD. Qt/KDE recompiles are a huge time sink of a regular portupgrade -a run; esp. on mini-ITX. Same for firefox/mozilla/thunderbird updates! Worse is only a complete GNOME upgrade (yikes!).

But seriously, gcc sucks big time (speedwise) when compiling C++ code like Qt or KDE or Mozilla. Absolutely rock bottom performance. One ought to force GCC developers to use only slower (.le. 500 Mhz) CPUs for a while, so that they'll learn to value fast compile times for a change. :-(

KDE 3.4 users (Alioth packages) BEWARE!

[andersa]

The changes has broken the experimental packages of KDE 3.4.1 on Alioth because of unfulfilled dependencies.

If you use those packages you should hold off with this upgrade for a while as it will cause many of the core KDE packages to uninstall breaking KDE completely.

Re:KDE 3.4 users (Alioth packages) BEWARE!

[Anonymous Coward]

What gets broken? I've just done the upgrade to xorg, and my KDE 3.4.1 from Alioth doesn't seem to have any problems (or at least, none that I've seen so far).

Re:KDE 3.4 users (Alioth packages) BEWARE!

[sewagemaster]

i don't have any problems with alioth 3.4.0 packages. i havent been able to upgrade to 3.4.1 anyway... cant seem to authenticate the pages via apt-get for some reason. how did you get around that?

Re:KDE 3.4 users (Alioth packages) BEWARE!

[andersa]

libglu1-mesa conflicts with xlibmesa-glu IIRC.

You may not have a complete upgrade if you haven't seen this. The upgrade will hold back some packages that causes this conflict if you don't do anything manually. In that case you are probably still running xfree86 instead of xorg.

Or the packages may have already been rebuild. I can't check that right now though.

Maybe it is true...

[ratta]

but none will do this now, as the whole desktop is moving towards something completely D3/OpenGL based, like Xgl, so the problem does not exist anymore.

Re:gentoo leads

[zr-rifle]

This is going OT, but multi day compiles of KDE are actually a thing of the past.

Nowadays Gentoo encourages the use of split ebuilds that make for a much more efficient and less bloated desktop, not to mention faster compile times, since only explicitly requested stuff gets compiled and installed.

Gentoo KDE Split EBuilds HOWTO

Sid only now runs X.org

[wot.narg]

What do you mean sid only now runs X.org?

My sid has been running x.org for a good 6 months :)

Woohoo!

[uncreativenick]

This means I can stop using Debuntu! (debian with some ubuntu thrown in) Thanks Debian X strike force!

CowboyHat linux had that awhile back

[Anonymous Coward]

CowboyHat linux (the distro named after Cowboy Neal and his wife Red Hat) and Fedora have had this for ages. What's the big deal?

Is X.org in some way tied into nvidia lockups?

[Sark666]

I have debian sid installed with Xfree still without issue. I've always just installed the nvidia binaries from their site with no problems. I also wanted to check out ubuntu and installed it and still have no issues with nvidia binaries, not a single crash/lockup.

However, a lot of people seem to have this dreaded X lockup with nvidia binaries, and just about all of them were using Xorg. This can either be a complete freeze, or the pointer still moving but nothing is responsive. Usually you can still kill X but not always. This has also happened to my brother who was frustrated with mandrake and packages, so I recommended ubuntu to him. I went over to his house installed it and everything seemed fine. Then he had a lock up an hour in. Then another. The weird thing is, it doesn't usually happen during playing say an opengl game, but usually on the desktop by just moving the pointer quickly.

He never had these issues with mandrake 10. I installed various versions of the nvidia binary including the one he used to use with mandrake but all the same. I looked at the specs of mdk 10 (2.6.3 Xfree86). I'm not sure if it's a kernel issue, Xfree, or some other thing like (apci or apm?)

The logs give an error (i believe nvrm xid error) but nothing that would lead one to a solution.

Please don't reply to this saying this isn't a tech support forum. I've searched many forums trying to help my brother. At nvnews.net there are a couple of threads that go on for about 20 pages with many users having this problem with no solution in sight. I just thought I'd take a stab at the /. Maybe one of you have dealt with the problem and actually solved it.

Re:Is X.org in some way tied into nvidia lockups?

[potHead42]

I've experienced this problem too (frozen screen with pointer still moving), but since I disabled acceleration for the render extension it went away. All you have to do is add the following line (or change it if it's already there) in the device section of your nvidia card in xorg.conf:

Option "RenderAccel" "false"

Also make sure you've disabled the composite extension, as it's still unstable.

hth

Re:Is X.org in some way tied into nvidia lockups?

[Sark666]

Sorry, I should have expanded on the things I've tried. One of the first was the renderaccel option, which didn't help. Besides trying ever nvidia binary under the sun, we next tried flashing his bios as some have reported that helped. Then I compiled a custom kernel as the ubuntu kernel as rivafb support compiled in.

I've stopped at that point, wanting to investigate more before trying more drastic things, like going to 2.6.3 kernel as thats what worked for him in mdk. Also considered going to xfree86 as thats available in ubuntu. I just find it really strange that mandrake was rock solid for him and ubuntu isn't. It seems to be a very illusive problem that some have solved with what you have done, some have solved it with flashing a bios etc.

But there doesn't seem to be an exact answer on what the actual underlying problem is. But thanks for your reply.

Re:Is X.org in some way tied into nvidia lockups?

[Anonymous Coward]

I have experienced similar lockups on Gentoo/X.Org when module parameter NVreg_EnableAGPSBA=1 has been enabled, but the card/motherboard has not supported it.

Re:Is X.org in some way tied into nvidia lockups?

[Anonymous Coward]

The strange NVIDIA lockups actually went away for me when I switched to xorg. They seem totally random, and what works for one person does not work for another.

Re:Is X.org in some way tied into nvidia lockups?

[Anonymous Coward]

I was having the same problem but with a previous X version, so I changed the AGP velocity in the BIOS from 4x to 2x, and then I got no more lockups. This was with an old TNT2 card.

Re:Is X.org in some way tied into nvidia lockups?

[CurlyG]

Sorry to be replying without a solution, but maybe it will help in narrowing down possible causes.

Mainboard: Shuttle SB77G5
Video cards tried: NVidia GeForce 4400 MX and GeForce FX5200
XFree86
Debian Unstable
Kernels tried: 2.4.27, 2.6.10 and 2.6.11
NVidia drivers 7174 and 7667

I've had *exactly* the same problem you describe - it seems to happen when web browsing, particularly with Firefox (several versions) but also occasionally Galeon and Mozilla. Just as you saw yourself, the display freezes (usually when flipping between tabs) but the mouse pointer is still working. Sometimes if I'm *very* quick I can restart X, but generally it's cold-reboot time.

Re:Is X.org in some way tied into nvidia lockups?

[Anonymous Coward]

I suffered the same Xorg lockup problem under Gentoo. Seeing many others with the same issue on the Gentoo forums I waited 4-5 months for a solution. Finally, I dumped Gentoo and tried Ubuntu (the hoarey hedgehog release). The same problem surfaced within a day. I dumped Ubuntu and tried the recent Fedora release. I've been running it for weeks now and have not had any problems.

Re:Is X.org in some way tied into nvidia lockups?

[Rysc]

For me it happens mostly in 3D apps (e.g. quake) and when running KDE, but not at other times. After turning renderaccel off it most often unfreezes after a short time instead of remaining locked.

For fun, strace XFree86 while the system is frozen (you'll have to ssh in).

Actually not affected by the C++ ABI transition?

[bartvh]

It turns out the x11-xorg glu library is not really affected by the C++ ABI transition (glu has a C-only API but uses C++ internally). My advice : wait until updated packages are there.

Re:gentoo leads

[Solosoft]

Well if your really intrested. I compiled KDE 3.3 in 4 days with make -j 3 . (of course that's only the base system and not all the packages and of course all the optimization flags for my CPU cranked)

That's of course on a Dual Pentium Pro. I compiled it and ran it for 3 days then got over it and went to windowmaker. I only compiled it for fun.

Now that machine sits headless in the corner folding protiens and hosting my crummy website

Re:wow

[hahafaha]

It appears to me that your experience iwth Debian has ended 3 years ago. Programs get updated and made better. Even so, some prejudices persist, and people choose not to use the system. That's OK. But there are those that choose to stay and make the system better for everyone. It is on this principle that all of GNU/Linux is based. And if you choose to discourage people from upholding this principle, then no matter what distribution you use, and even no matter what operating system you use, you are not understanding the significance of freedom.

Install X.org, remove 1/2 your system

[hacker]

Yes, I too upgraded to X.org, specifically to get the DynamicCLocks feature working on my Thinkpad T42p to increase battery life and reduce heat on the GPU.

Unfortunately, installing X.org, and JUST X.org, required the removal of 526 packages from my system (yes, exactly 547 packages, which you can see here, sorted alphabetically).

This included all of GNOME, themes, widgets, applets, all of KDE and related packages, pose (the Palm OS Emulator) and its foundation lib FLTK, abiword, OpenOffice.org, and hundreds of other packages.

After installing X.org back on, I was able to install about 100 of those packages back onboard, but now there's a nice diversion between the two xlib versions. I can't install Abiword for example, without pulling out gaim, gedit, gnome-core, and a few other libraries. Its like this with about 300 of the packages I had onboard before. pose won't install because it requires libfltk, and libfltk requires htmldoc. Installing htmldoc requires libfltk (another circular dependency).

This reminds me of the pain we went through with the libc5 => libc6 migration, except now we have the gcc4 ABI change and X.org breaking everything that uses a colored pixel.

Nice... it'll be a few months before its all sorted out, no-doubt.

Re:Install X.org, remove 1/2 your system

[Anonymous Coward]

This reminds me of the pain we went through with the libc5 => libc6 migration, except now we have the gcc4 ABI change and X.org breaking everything that uses a colored pixel.

Wow, I wonder why they call it unstable (rolls eyes).

If you think that was annoying, I don't know what you'll do when serious issues surface after upgrading.

Re:Install X.org, remove 1/2 your system

[Erik Hensema]

If you want stability, then don't run debian unstable. You'll probably be far better off on ubuntu, which essentially is debian unstable, stable.

Re:Install X.org, remove 1/2 your system

[kylegordon]

See that word "unstable"? Look it up in the dictionary. See that name "sid" - did you ever stop to think that it stands for "Still In Development"?

"I run Debian Unstable. But I'll still moan like a fucking drain when it breaks..."

Re:Install X.org, remove 1/2 your system

[Chanc_Gorkon]

Agreed. It's been the best distro I have ever tried for a extended period of time. I had Red Hat 6 a long time ago and while it was ok for the time, Ubuntu is loads better..

Re:Install X.org, remove 1/2 your system

[Anonymous Coward]

He probably didn't think that because it isn't true.

What is sid?

Sid is the unstable branch of Debian. All of Debian's branches and releases have "code names" which are from the movie Toy Story. For example, Debian 3.0 is code-named "woody". Sid was the kid who broke all the toys. Some people think sid is an acronym for "Still In Development". This is cute, but inaccurate.

From the Debian sid FAQ; http://wooledge.org/~greg/sidfaq.html#1

Re:Install X.org, remove 1/2 your system

[rodgerd]

Unfortunately, some Debian fans have taken to advocating for Debian test and unstable as "server" and "desktop" ready distributions, respectively, whenever there are gripes about the Debian release cycle. Even more unfortunately, people listen to them.

Re:Install X.org, remove 1/2 your system

[/dev/trash]

sid was teh kid who destroyed toys, in Toy Story.
+++
My last.fm page
+++
Husi is where's it at

Re:gentoo leads

[jiushao]

Then I have good news for you (though you should have noticed it yourself); g++ performance is improving by leaps and bounds as of late.

The new hand-written recursive descent parser added in 3.4 improved performance a fair bit (making 3.4 the fastest g++ version ever as of the release they claim). The performance for compiling without optimization was improved even more in 4.0. For Gentoo users and other OCD-level recompilers it might not matter, but it does help developers everywhere. This is what I would personally call the place where it matters, end users that obsess over recompiling stuff themselves for no reason can wait.

It is overall a general consensus among gcc developers that performance should be improved. Don't expect C-level compilation speeds from C++ though, it is a heavy language to compile by nature. This keeps getting worse with the increasing prevalence of extreme template metaprogramming libraries like Boost, to a great part in meaningless areas in a quest for performance that will never matter or materialize (I don't claim that Boost or template metaprogramming is a bad thing, just that people obsessivly use it in places where normal coding practices would do just as well except for imagined performance/purity issues).

Re:wow

[Mr2cents]

I switched distro's every two years on average until I found Debian. Nearly 4 years later, I'm still impressed by it's package management.

Re:gentoo leads

[Anonymous Coward]

Why the hell do you compile code on a 'mini-ITX'. Learn something about embedded hardware. You get it compiled OFF the box by yourself or by someone else. When necessary, you crosscompile. Or did you think NetBSD is compiled on the hardware it runs on? Ofcourse not, is all done via crosscompiles on fast machines -- for a reason.

If you want faster C++ code, try diff compiler (version), use prelinking (faster C++ code _execution_), or just compile on a faster box.

nvidia glx migration issue

[Anonymous Coward]

I ran into this when migrating from the xfree86 to the xorg server in sid:

http://www.nvnews.net/vbulletin/showthread.php?t=2 8708

Problems with trident/white screen

[blonde rser]

I know I shouldn't use /. as a technical forum but I'm going to anyhow. A few days ago I upgraded to x.org in debian and it discovered my on board video card as a trident compatible just fine. But when x.org started all I got was a white screen and my virtual terminals went hay wire. So I rolled back to xfree86 which continued to work. Has asyone else had this problem. Has it been corrected?
Thanks

Re:Problems with trident/white screen

[Anonymous Coward]

That's the exact same on my system. Hopefully they'll fix it soon as I'd rather not buy a new video card. Also kdm takes forever to load (several mins.); this problem only started after I went to X.org then back to XFree86. This is realy starting to anoy me!

Re:Problems with trident/white screen

[pintpusher]

same prob with an old Trident TGUI9440 (actually mine is a 9441 I think)... white screen -- terminals unusable. SSH'd in from another and apt-get installed xserver-xfree86 (after many attempts to make it work) now back up and running though my config files are now so fscked that I get a million and one warnings etc on startx. the problem is, how long do we wait for it to fly again? I'm not relishing doing this over and over til it finally works.

There's not enough information

[Sits]

Unfortunately there are lots of reasons why it could be going wrong.

Honestly the best thing you can do is to post to the nv forum and then send a message to NVidia themselves (see the "CONTACTING US" part of the README that came with the drivers). You may well have hit a genuine problem (Which only NVidia will be able to confirm) but you don't provide enough information - (which card? What were you doing at the time? Were there any Xids? The list goes on and on). *Don't post the reply to those questions here* though - go to NVidia. That way you can skip the speculation. Good luck.

What news?

[RWerp]

So debian folk is moving to X.Org? Yawn... I had it on my machine for a year already. Glad you crawled from under that rock of yours.

XInput broke?

[grumbel]

I did the X.org upgrade in Debian today and everything went smooth, except xinput, which is no longer working for me, Gimp doesn't show the devices (graphic tablet) at all and xinput shows them, but fails to read from them:

$ xinput test gstylus
X Error of failed request: BadDevice, invalid or uninitialized input device
Major opcode of failed request: 150 (XInputExtension)
Minor opcode of failed request: 3 (X_OpenDevice)
Serial number of failed request: 11
Current serial number in output stream: 11

Does anybody know what is wrong?

Re:XInput broke?

[grumbel]

Figured it out, problem actually didn't have much todo with xorg itself, but with a bunch of other Debian upgrades happening at the same time.

First of the wacom module build per default with gcc-4.0, but needed gcc-3.3, else it gets rejected by the kernel, manually tweaking the symlink /usr/bin/gcc helped to force a build with the right gcc version.

Secondly udev in sid requires kernel-2.6.12, but Debian only ships 2.6.11, so it won't start and some device files will be missing, workaround was to 'mknod' the missing /dev/input/event* files (MAKEDEV input only creates 4, while ).

After both of these problems were fixed the tablet works again flawlessly in xorg.

*yawn* oh, good to see debian waking up a bit

[v3xt0r]

Slackware has had X.org since 10.0 came out over a year ago.

I've tested w/ a GeForce FX 5200 and an ATI Radeon 9200SE, and both worked fine (@ 1920x1440@75hz on 21" Sony E540), although I had to install nvidia drivers for the GeForce (but not for the radeon), all went with minimal hassle.

But, KDE has a conflict

[Nate B.]

I built a Sid partition on this laptop to try out Xorg. Quite well done! Easiest X install this side of KNOPPIX. Also the Sarge installer was top notch as well. The only problem I've seen is that the kde package depends on an older library provided by MESA and that conflicts with a newer one installed with xorg.

So, to install kde I must uninstall xorg, or thereabouts. At least that's the impression I'm getting from Aptitude. Ah well, I'll give it some time to sort out.

Re:gentoo leads

[Deraj DeZine]

I switched from Debian to Gentoo over a year ago and I am currently running Gentoo.

My advice: DO NOT use Gentoo. I thought Debian unstable updates were a pain (things breaking, packages not ready yet, etc.), but I tried upgrading a pretty average Gentoo installation and nearly half of the programs I used everyday stopped working.

I plan on switching back to Debian ASAP, but I really need x.org, so I've been putting it off until this (great) news comes along.

Re:wow

[Anonymous Coward]

In reverse order, 2 of those people are idiots, 1 of them a bearded whacko but still cool, and the other... Well, I got nothing against Linus.

But Debian is still the best Linux IMHO.

And after 5 hours

[RingDev]

I still can't get my ATI x700 to come up on Gnome/Xorg in Ubuntu. But Mandiva and XFree86 comes up no problem. bleh. -Rick

opengl on my laptop!

[rbrewer123]

With x.org running and the savage DRI drivers from dri.freedesktop.org, I can finally get opengl acceleration on my laptop (a 3 year-old Toshiba with Savage 16 MB graphics chip). I'm not really into games, so that was never a big deal for me. But it is nice for messing around with here and there. Also, I have noticed that firefox scrolling performance is better with x.org, there is no tearing when scrolling slashdot. And that's what it's all about! :) For those trying to get opengl running, glxinfo is your friend. If it says "direct rendering: Yes" then you have hardware accelerated opengl. If it says "no", you don't. You can also run glxgears and look at the fps counts. Mine jumped from 100-160 fps to around 300 fps with hardware acceleration. -Rob

mmmm

[Anonymous Coward]

and will be in the stable distribution ... well.. in about 50 years.. no? :-)

Half a gig, half a gig, half a gig onward...

[Renegrade]

You should not use glTranslate3f at all with 2D.

If you aren't using Translate, your pixel/poly ops will not align correctly with point and line ops (see appendix H of your red book) - this can be seen in certain Accolate products :P

Instead, use dynamic vertex buffer objects. Similarly, use pixel buffer objects for the textures (the window contents). And no, nowadays almost nothing is done by the CPU. Just commands are sent, and in this case, vertex data is transmitted. But transfer is mandatory anyway.

Aah, so the GPU is now responsible for system heap allocation. Glad to know a non-local processor is handling memory allocation. This still involves considerable CPU intervention, especially with the allocation and management of these 1.5-only objects. When you're updating verticies, what do you think is happening? Some magical GPU prediction of your next update? This all still has to be processed by the OpenGL pipeline, which is deep and complex and interlaced with both CPU and GPU interactions (Read the Apple Developer Guide).

Also, consider this: While your OS is bloating up the video memory, what's happening to your 3D applications? They don't mind that suddenly you have half the texture memory, or that something is consuming GPU time?

Ever seen a GL GUI? Those things are *FAST*.

To quote Dave Haynie, even crappy architecture is fast when run at 200mhz. I haven't seen anything that ISN'T fast-looking lately. Especially since Dave's 200mhz is now more like 2000mhz. However, the magic is in not using up all the resources _before_ the application starts. My old Amiga 1200 could boot up in seven seconds (including POST) off of a generous 12-meg partition, and surf the web while running multiscreen IRC sessions and a few FTP clients, with 2 megs of video ram and 4 megs of fast ram. I'm just waiting for the next version of Windows/MacOSX/Redhat to announce memory requirements that cannot be handled by a 32-bit addressing range.

With a 2D blitter, you have to perform conversions too (32->16 bit for instance). The CPU has to do setup for a 2D blitter, too

2D blit setup is less than trivial unless there's overlapping regions, and then it's just _trivial_. Integer conversions are also less than trivial, bit ops are sub-cycle for a processor, and sub-sub-cycle for a proper blitter. Floating-to-integer conversions are much less trivial, as floats are more complex and totally incompatible with integers, and require serialized operations (you cannot shift the mantissa until you've extracted and subtracted the exponent down to it's real level, whereas you can extract all four color components and recombine them in an orderless manner (r|g|b is equal to b|g|r which is equal to r|b|g which is..) ) which will not take advantage of modern pipelined _anything_.

No, you are complicating it. As I said, GL GUIs are real and blazing fast. There are tons of GL GUIs for SDL, and ClanLib renders *everything* with GL (yes, the 2D stuff too).

Quoting from Apple, "In OpenGL, there are several obvious and other not-so-obvious ways to cause either the CPU or GPU to stall on the other." ... I'm complicating it because it is complicated, and complicated = evil in computing. See above regarding "Fast".

Yes, the lesser machine is a problem. However, 3D support is not. Today, EVERY graphics chip set supports basic 3D rasterization and T&L. In case where there is no support available, simply fall back to traditional methods.

This ATI Charger 512 does not support ANY of that (nor blitting for that matter), and this Rage II here only has the basic rasterization. I don't really know the specs for this S3 Trio64, but I doubt it's more than basic rasterization too, and rather slow rasterization at that. Also see the

Re:Half a gig, half a gig, half a gig onward...

[ardor]

If you aren't using Translate, your pixel/poly ops will not align correctly with point and line ops (see appendix H of your red book) - this can be seen in certain Accolate products :P

You don't need Translate for that. Just add 0.5 to the x/y-coordinates (assuming that you set up an orthogonal matrix with 1.0 = 1 pixel).

Aah, so the GPU is now responsible for system heap allocation. Glad to know a non-local processor is handling memory allocation. This still involves considerable CPU intervention, especially with the allocation and management of these 1.5-only objects. When you're updating verticies, what do you think is happening? Some magical GPU prediction of your next update? This all still has to be processed by the OpenGL pipeline, which is deep and complex and interlaced with both CPU and GPU interactions (Read the Apple Developer Guide).

Well, what is happening? The card processes the data I gave it last time, while I am filling the buffer with new data. I'm not entirely sure if this behaviour is fully implemented in dynamic VBOs, it IS implemented in dynamic D3D VBs with the "discard" flag, however.
Besides, anyone how had to do stuff like complex particle systems or extensive 2D output using 3D had to address this issue.

Also, consider this: While your OS is bloating up the video memory, what's happening to your 3D applications? They don't mind that suddenly you have half the texture memory, or that something is consuming GPU time?

Bloating up? Oh come on. How much space is that geometry gonna take? You don't have to create a PBO for each window, you can reuse one, or create a couple of them and reuse them, but for EACH window a PBO/texture is a total waste. Besides, you are not going to use mipmaps, so another space-wasting thing is removed.

So that leaves us with geometry, which almost NEVER fills up half of the GPU RAM (except when dealing with models with about 12 million triangles). Taking up half of the mem is ridiculous. Does your card have only 512 KB RAM?

As for Quake 4: you do *not* have to repaint the GUI all the time; just when its needed. So Quake 4 won't get into trouble unless the entire GUI is updated all the time.

2D blit setup is less than trivial unless there's overlapping regions, and then it's just _trivial_. Integer conversions are also less than trivial, bit ops are sub-cycle for a processor, and sub-sub-cycle for a proper blitter. Floating-to-integer conversions are much less trivial, as floats are more complex and totally incompatible with integers, and require serialized operations (you cannot shift the mantissa until you've extracted and subtracted the exponent down to it's real level, whereas you can extract all four color components and recombine them in an orderless manner (r|g|b is equal to b|g|r which is equal to r|b|g which is..) ) which will not take advantage of modern pipelined _anything_.

This is all totally irrelevant since you usually use integers for textures (unless you use HDR floating point textures). And the fillrate of today's cards is enormous. Basic setup for a 2D-OpenGL-Blit is also absolutely trivial.

Quoting from Apple, "In OpenGL, there are several obvious and other not-so-obvious ways to cause either the CPU or GPU to stall on the other." ... I'm complicating it because it is complicated, and complicated = evil in computing. See above regarding "Fast".

Absolutely. But this does not rule out fast rendering. Not at all. Also, if you follow some rather logical rules, you won't end with a crappy performance. Like, using VBOs for geometry, since they are very well optimized, both for static and dynamic geometry (on the other hand, do NOT use glVertex3f unless its not possible to avoid it).

This ATI Charger 512 does not support ANY of that (nor blitting for that matter), and this Rage II here only has the basic rasterization. I don't really know the specs for this S3 Trio64, but I doub

Re:Half a gig, half a gig, half a gig onward...

[Renegrade]

You don't need Translate for that. Just add 0.5 to the x/y-coordinates (assuming that you set up an orthogonal matrix with 1.0 = 1 pixel).

Aah, so we'll use the processor's floating point unit(s) to add to all coordinates instead of the 3D card's T&L processing unit during the absolutely required and unescapable matrix transforms? Even in Ortho2D mode, both projection and modelview matricies are in use. The upside of that is that the Transformf/d is effectively done in T&L hardware once the matrix is set up. Unless, of course, this hardware is already tied up doing something else, or doesn't exist to begin with.....

Well, what is happening? The card processes the data I gave it last time, while I am filling the buffer with new data.

Buffers aren't like magical queues that have no overhead for syncronization and filling. Something's going to have to do this work, and guess what? The CPU/motherboard chipset is the final arbiter of all bus operations.

I'm not entirely sure if this behaviour is fully implemented in dynamic VBOs, it IS implemented in dynamic D3D VBs with the "discard" flag, however.

I tend to stay away from DirectX as I detest 90 meg downloads (part of the bloat I mentioned), vendor lock-in and MS/Com/Com+/brain damage.

Besides, anyone how had to do stuff like complex particle systems or extensive 2D output using 3D had to address this issue

Note that 2D _is_ an issue in OpenGL, which effectively is never really 2D. All internal ops are performed in four dimensions, with W=1 during normal 3D ops, and Z=0 during "2D" ops. Most particle systems use billboarding, which incidentally, is CPU-bound as the card typically doesn't give you an API to cross product or normalizing functions. (Getting a raw raster image into 3D space would be.. ugh, Un/ProjectMatrix crap)

Bloating up? Oh come on. How much space is that geometry gonna take? You don't have to create a PBO for each window, you can reuse one, or create a couple of them and reuse them, but for EACH window a PBO/texture is a total waste. Besides, you are not going to use mipmaps, so another space-wasting thing is removed.

If you don't have a texture/pixel object for EACH window, where is the window coming from when it's being redrawn? ... PROCESSOR MEMORY? There must either be a texture/object for each window on the screen being handled by OpenGL, OR it must be reloaded from system ram (ooh so fast, requires muchly painful CPU intervention), which will either make the aforementioned bloating become real in the former case, (recall that textures typically have to be square, really efficient for rectangular windows) or for the supposed performance/efficiency to vanish in the latter case.

NOte that mipmaps don't take much memory, and if you don't use them, the mipmap support structures must still be in place. Remember that the second mipmap is a quarter of the size of the first, and that the third is a quarter of the size (memorywise, of course) of the second. It's the main texture that bloats up all the memory, relatively speaking.

So that leaves us with geometry, which almost NEVER fills up half of the GPU RAM (except when dealing with models with about 12 million triangles). Taking up half of the mem is ridiculous.

Actually 12 million triangles would overflow most cards memory by a wide margin, just on verticies alone, unless your card manages to store them efficiently.

Does your card have only 512 KB RAM?

Oh hell yah, that ATI Charger was upgraded to 512KB at a cost of um.. $70! It is the total pwn now.. ..or it was, at least, lol

As for Quake 4: you do *not* have to repaint the GUI all the time; just when its needed. So Quake 4 won't get into trouble unles

Re:Half a gig, half a gig, half a gig onward...

[ardor]

Yeah, it IS getting off-track, so I'll make it short as well:

• Several render paths bloat up the OS? Do you really think that another renderpath would be responsible for 200+ MB additional size?
  If cleverly designed, and with modularization in mind, one can create those renderpaths independently of each other. Talk about plugins. Also, you DO NOT HAVE TO USE IT if you don't want to!
• The 40 meg OS precedessors didn't behave like virtual machines - but thats exactly what they should do.
  Agreed, todays OS are oversized, but this is not the fault of a goddamn renderpath!
• Actually, no, the heavy part isn't done by the CPU if the driver manufacturers are smart. T&L with the CPU? Complex fragment programs by the CPU? Forget it. AGP transfers cost a lot, the bus gets saturated easily, especially in the card->sysmem transfer. Also, things like the fragment program are way too complex to be done with the CPU. While it is true that OpenGL may fall back to emulated mode where the CPU does all the stuff, today's ICDs are written quite well, and usually don't behave like this. And again: such a renderpath would *****NOT***** be mandatory.
• About the 1.5+ features: they are a driver issue ONLY. VBOs are supported by every card capable of T&L, PBOs are supported by just about every card, FBOs by every one who supports render targets. Due to their novelty, the drivers aren't adapted to these yet (VBOs are supported by almost every card, PBOs - less cards, FBOs - even less cards, since its brand new).

You are acting as if "the new Linux supporty only superduper OpenGL-supporting ultra cards". Again, this GL drawing would be an OPTION. You cannot forbid people to code an OpenGL renderpath for X11. They want it, and they want to create a new option for X, and it WILL exist, no matter if you like it or not. You know, not all people like super-spartan evilwm UIs, and I actually like some eye candy thank you very much. I WANT the Linux desktop to have the features OSX has. It is quite irritating that I have to defend myself every time because some l33t unix hackers see it as blasphemy that someone does not stick to yesterday's interfaces. Man, I'm glad that X11 managed to get truecolor video modes. Must have been a fierce battle.

Re:Half a gig, half a gig, half a gig onward...

[Renegrade]

• Any extra code is adding bloat. While I agree totally that it's not just the render path that's adding a half gig to every new OS release, it's the "we'll just add a few features here.." process which is applied to EVERYTHING in the operating system (including, say, render paths), increasing every feature's size by 50K. The end result is, after 10,000 upgraded features, a half gig.
• While it's true that the 9x / old Mac OSes were underprotected heaps of junk, the same is not true for the older Linux/BSD/NT series.
• I didn't say the heavy part was done in CPU, just that there is still much work done by the CPU. Recall that 99% of the code installed in a system is run by the processor, and modern drivers are huge. (You cannot tell me that nvidia is copying 30 megs into the GPU memoryspace..) Also, anything you program, aside from shader/vertex code, is executed by the CPU. (And also possibly by other components)
• Careful, the GeForce 256 board is a T&L card. I'd be surprised if it supported any of that in hardware, at all. 3D card makers love to cut corners.

The people wanting something has nothing to do about wether it's a good idea or not. In fact, the more people want something, the worse of an idea it is, generally speaking. (This is the biggest problem a democracy faces)

You know, I don't think I actually addressed X11, I certainly wasn't thinking of it. X11 is a nasty, slow, fat beast which I almost never use. I once left it running on my CD burning machine, and it managed to bloat out ~300 megs of memory with just two mozilla windows open on a gnome desktop. Kinda scary considering that the machine is only using ~60 megs right now, including ~16 megs of BOINC, without X.

I doubt true color was any problem for X. Getting rid of the old crappy VGA modes might be, though. How the f* did IBM come up with 18-bit palettes? They must have been smoking something pretty toxic. Six bits FTW! Oh well, they were never good at graphics anyways.

Oh, one thing I wanted to mention earlier is that a system designed off of advanced overlays (such as Phase5's aborted third-gen Amiga platform) would probably be a lot better than anything we've discussed for speed and simplicity on the CPU side.