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

changelogs

[bonk]

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

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.

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.

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

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

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

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

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