Slashdot Mirror
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."
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.
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.
" What luck for rulers that men do not think" - Adolf Hitler
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.
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.
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.
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
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.
GP was funny. Laugh.
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.
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
Hack your mind out of its sandbox.
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
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.
I Browse at +4 Flamebait
Open Source Sysadmin
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.)
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.
A deep unwavering belief is a sure sign you're missing something...
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!
A deep unwavering belief is a sure sign you're missing something...