Christmas Comes In July For An Open ATI (Phoronix) [LWN.net]

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 27, 2008 15:56 UTC (Sun) by shalem (subscriber, #4062) [Link]

I have an x1950pro, which is made on a smaller process and thus gets less hot. Works well with
current git radeon driver + mesa

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 27, 2008 16:00 UTC (Sun) by pheldens (guest, #19366) [Link]

thanks for the tip, passive cooling is a requirement for me too yes.

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 27, 2008 16:25 UTC (Sun) by PO8 (guest, #41661) [Link]

Kernel mode setting is where the graphics hardware is set up by the OS kernel, instead of
through some kind of weird peek-and-poke userland interface, as the OS Gods intended.  It
turns out that properly initializing a modern graphics chip, which typically has literally
thousands of bizarrely-organized registers, is usually the hardest part of getting it up and
running.

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 27, 2008 18:42 UTC (Sun) by oringo (guest, #44517) [Link]

So does this mean that Linux kernel is on a fastrak to be as bloated as the NT kernel?
Seriously, I'm actually concerned.

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 27, 2008 18:55 UTC (Sun) by yoshi314 (guest, #36190) [Link]

not really. this means that resolution switching code will move to the kernel, which means
that console framebuffer drivers (like vesafb) will work better with X.

as demonstrated on phoronix some months ago with a working kernel modesetting for intel cards,
VT switch (switch to console from X) is nearly instantenous, when using kernel modesetting.

so in short - kernel will manage resolution switching, and low-level video stuff. right now
you need separate framebuffer driver for hi-res console, and separate X driver. and they might
not play nicely with each other (think about nvidia and rivafb, for instance). sometimes VT
switch takes even 3 seconds, and it's not guaranteed to be stable.

all the high-level stuff, like opengl and 2d acceleration will still be done higher, working
on top of low-level DRM kernel modules, which will provide the necessary infrastructure.

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 27, 2008 18:59 UTC (Sun) by nix (subscriber, #2304) [Link]

This is also a precondition for getting DRI working in multiple X servers 
on the same machine at once, and it's a substantial code *simplification* 
(or at least it would be if the non-kernel-modesetting code could be torn 
out, which it can't as that would break old kernels and non-Linux 
systems).

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 27, 2008 22:12 UTC (Sun) by drag (subscriber, #31333) [Link]

Yep..

Better, faster, cheaper (simplier).

There are several important things going on with this:

* This makes a flicker-free Linux experience, as mentioned by other people. This means it's
possible to have full color and graphics from grub to shutdown.

* This will eventually improve reliability of power management as modsetting is a big problem
for suspend and wakeup. Users end up with blank screens or scrambled displays and that sort of
thing. 

* Along with improvements to the DRM interface for video card memory management it makes DRI
work better.

* It's a important step for moving X Windows out of the job of managing hardware. When they
manage to get the X Server using standard graphics APIs instead of mangling PCI resources and
having it's own special drivers, then that will allow users to have their X Server running
entirely under their own account. No root access required. This is important for security,
reliability, and multiuser improvements. 

Don't worry. Nobody wants to pull a Nvidia and stuff way to much functionality into a kernel
module. :)

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 27, 2008 23:03 UTC (Sun) by nix (subscriber, #2304) [Link]

Some people try to stuff a lot of functionality into the kernel: 
http://savannah.nongnu.org/projects/schemix/ (appears to be dead, 
perhaps because all the developers went insane).

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 28, 2008 9:38 UTC (Mon) by wingo (subscriber, #26929) [Link]

I just want to say that that link is triple awesome.

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 28, 2008 10:17 UTC (Mon) by tialaramex (subscriber, #21167) [Link]

Actually that is sort-of awesome. If you're going to bolt a language into the kernel then it
only makes sense for it to be Scheme, not only because it short-circuits Greenspun's Tenth
Rule but also because Scheme users won't be disappointed by the kernel's rather sparse
amenities. And even better on a modern kernel you'll run out of stack almost immediately which
makes it exactly like trying to use a real Scheme implementation on old hardware (or in my
case, thousands of them in parallel on 1990s hardware).

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 28, 2008 14:47 UTC (Mon) by nix (subscriber, #2304) [Link]

Well obviously the sane thing to do is to make the Scheme stack not be implemented in terms of
the C stack.

This makes it easier to implement call-cc as well, and of *course* a kernel imeplementation of
Scheme needs call-cc. :)

(ideally you'd have jailed and non-jailed processes, where the jailed ones have access to no
more than a normal userspace process would except they're implemented by a kernel-space
interpreter. Ideally ideally it'd JIT-compile everything. I'm overthinking this.)

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 28, 2008 12:31 UTC (Mon) by jlayton (subscriber, #31672) [Link]

Another possibility that's been discussed (and one of the driving forces behind getting this
support in) is that this may allow us to display kernel oops messages to the screen even when
X is running.

That would be a wonderful, wonderful thing.

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 27, 2008 21:25 UTC (Sun) by ibukanov (subscriber, #3942) [Link]

> as demonstrated on phoronix some months ago with a working kernel modesetting for intel
cards, VT switch (switch to console from X) is nearly instantenous, when using kernel
modesetting.

The kernel in Fedora 9 has the modesetting for Intel chips that one can activate via passing
i915.modeset=1 to the kernel command line. When I activated it on my Latitude X1 laptop, the
kernel immediately during the boot switches to the native 1280x768 resolution for the console,
X startup does not flush any longer and the VT switch becomes really instant. 

For the moment the support is rather buggy. The display stays dead after the suspend and video
players show a garbage. But I do have high hopes for Fedora-10 :).

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 28, 2008 9:46 UTC (Mon) by jamesh (subscriber, #1159) [Link]

The code for mode setting needs to go somewhere.  If it isn't in the kernel it will need to be
somewhere else.

If the code is in the kernel, then it should be able to reliably save and restore the video
mode over a suspend or resume (since the ACPI spec gives no guarantee over what state the
hardware will be in on resume).  This beats hacks like trying to rerun the video BIOS
initialisation code under an x86 emulator or VM86 mode.

I'm not sure why you wouldn't want the kernel to be able to initialise the primary output
device of your computer ...

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 28, 2008 14:41 UTC (Mon) by i3839 (subscriber, #31386) [Link]

All kind of useful info, including kernel mode setting: http://keithp.com/blog/

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 28, 2008 19:20 UTC (Mon) by rvfh (subscriber, #31018) [Link]

I warmly recommend reading Keith's blog, really gives a good idea of what's going on. And
what's to come! Awesome... Can't wait!

Also, I look forward to the day when we have a flicker-free nice screen from boot to X,
because the other two have it and it makes them look better.

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 29, 2008 9:08 UTC (Tue) by odie (guest, #738) [Link]

Indeed. I'm looking at a black, slightly flickering screen for several seconds while logging
out or switching users. My girlfriends computer with similar specs shows snappy, smooth
transient effects instead.

I'm one of the people who uses and loves the network transparent aspects of X, but I still
think it needs better hardware handling. Another example, which if I understand things
correctly might be helped by this down the line: If I switch user (aka run a second X server
in parallel), I can't use video overlays or accelerated 3D.

A nore layered system would probably be preferable. While you're at it, why not decouple the
network part from the graphics part, so when a graphics driver crashes, all the windows are
still there when it restarts?

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 30, 2008 23:19 UTC (Wed) by bronson (subscriber, #4806) [Link]

> While you're at it, why not decouple the network part from the graphics part, so when a
graphics driver crashes, all the windows are still there when it restarts?

Yeah, it's surprising that X still can't do this.  I thought that libxcb solved this but I
don't see anything about it on its wiki http://xcb.freedesktop.org/.  I understand that this
limitation is also baked deep into GTK+ and will take some serious effort to fix.

In addition to crash persistence, why can't I disconnect an app from one display and connect
it to another one?  That way my phone could display my calendar on the desktop machine.  When
I take the phone out of 802.11 range, it would just use its local screen again (This becomes
even more useful when process freezing and containerization become easy; I'd like send the
entire app -- not just displays -- between computers).

This is coming and I hope it's on Linux first.  Alas, apparently X11+Toolkits apparently still
have quite some work to make it possible.

Christmas Comes In July For An Open ATI (Phoronix)

Posted Jul 31, 2008 14:50 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

Unix workstations tended to put mode setting in the kernel or firmware. Xorg is anomalous
because it's derived from XFree86, which was originally written for proprietary Unixes on x86
without suitable kernel APIs.

Christmas Comes In July For An Open ATI (Phoronix)

Posted Aug 1, 2008 9:24 UTC (Fri) by njs (guest, #40338) [Link]

XCB has nothing to do with this, as far as I can tell.

There's actually quite a bit of code/design in GTK+ towards making it possible to move between displays etc. -- if an app wants to move a window from one server to another, about all it really has to do is unrealize the window, set the window's current screen to the new display, then show it again... about 3 lines of code. But there's no way to tell an arbitrary app to run those 3 lines of code, plus there are a bunch of niggling details to make things seamless, plus the crash recovery case is worse because when the server has just *disappeared* then you can't run your normal cleanup code against it. Still, sitting down and trying to make all this work wouldn't be a totally crazy thing for someone to do...

In the mean time, I wrote a little tool called xpra that I use for running remote/persistent X apps -- maybe it'll work for you too. (NB the last release has a nasty bug in focus handling that affects Qt apps but not GTK+ ones; the fix is on mainline, so I really should roll a tarball one of these days...)