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?

[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

changelogs

[bonk]

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

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

[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

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...

[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...

[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...

[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...

[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)

*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*

[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.

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)

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?

[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".

*mumble*

[Simon Kongshoj]

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

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 =)

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

[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.)

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 ...

[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 ...

[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 ...

[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 ...

[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: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?

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.

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: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: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: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.