Christmas Comes In July For An Open ATI

[phoronix]

Phoronix: Christmas Comes In July For An Open ATI

Many Linux users will be celebrating the Christmas holiday in five months, but it seems there's a holiday worth celebrating today for open-source ATI Linux users.Just hours ago AMD released a new AtomBIOS parser, but there is even more worth celebrating. It turns out that David Airlie with Red Hat has been secretly working on kernel-based mode-setting support using AtomBIOS...

http://www.phoronix.com/vr.php?view=NjYyMQ

[ethana2]

I again congratulate AMD for being awesome. I can vouch that their commitment to FOSS has helped them sell three Radeon HD 4850's in my circle of friends alone.

All those folks at RedHat and Novell rock also.

[stan]

Yay! It would be cool to do kernel mode setting with Rage 128 cards using the r128 driver, too. Hopefully it wouldn't be too hard.

[Kano]

@ethana2

None of em want to play games with wine, right ;)

[Vadi]

Excellent news. Hope it bears fruit for AMD soon enough.

[sundown]

Yay, good job to David and RadeonHD.

@ethana2

None of em want to play games with wine, right ;)

No Kano, they dualboot, duhh ;)

[ethana2]

When we have FOSS drivers built on their open specs, WINE won't be an issue.

One of my friends got two of the cards and has them in crossfire. nVidia doesn't support SLI under linux.

[deanjo]

nVidia doesn't support SLI under linux.

Ummm, ya they have, for quite some time now, going on three years.

Crossfire however is still not supported in linux yet.

http://www.phoronix.com/scan.php?page=article&item=267&num=1

[ethana2]

Ummm, ya they have, for quite some time now, going on three years.

Crossfire however is still not supported in linux yet.

http://www.phoronix.com/scan.php?page=article&item=267&num=1

Whoa! That's a pretty bad misunderstanding on my part. :(
..well that's great! SLI under linux! ..heh.

<olaf>Thank you for corrrrrecting me :)</olaf>

[jeffro-tull]

good deal! I love seeing the progress being made. after almost two years, it seems like the video card in my laptop (X1300) will finally do everything I want it to under open source goodness. Hell, I might even have to upgrade my tower from a geforce 6200 to a R500 card.

[d2kx]

*celebrates and jumps around*

[Tillin9]

This really is great news. I really appreciate all the hard work. AMD has won at least a few dozen purchases from me (2 for personal use, the rest for work). I just really hope they don't forget the earlier radeon cards.

[d2kx]

Unfortunately, it doesn't build for me:

rhd_driver.c:1148: error: ‘struct RHDRec’ has no member named ‘DMAForXv’
rhd_driver.c:1004: warning: unused variable ‘DriScreenInited’
make[3]: *** [radeonhd_drv_la-rhd_driver.lo] Fehler 1
make[3]: Leaving directory `/home/d2kx/xf86-video-radeonhd/src'
make[2]: *** [all] Fehler 2
make[2]: Leaving directory `/home/d2kx/xf86-video-radeonhd/src'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/d2kx/xf86-video-radeonhd'
make: *** [all] Fehler 2

This is what I get at the end... any ideas?

[bugmenot]

Unfortunately, it doesn't build for me
Yep, the same problem for me. :(
Ubuntu 64 Bit
Any Suggestions?

edit: Someone helped me in irc: http://radeonhd.org/index.php?page=archive_display&s=Hello&c=radeonhd&m=7&y=2008&d=2008-7-26#result
After installing the packages everything worked :)

[Zhick]

Whoa! That's a pretty bad misunderstanding on my part. :(
..well that's great! SLI under linux! ..heh.

<olaf>Thank you for corrrrrecting me :)</olaf>

Actually you were mostly right. Sure, you can add a second video-card to your pc, and the nVidia-driver will tell you it's using the cards in SLI, but that's about it. There's practically no performance-gain.

My guess is when Crossfire hits fglrx it will be way superior to nVidias SLI in terms of performance gain, but honestly I don't care. SLI and Crossfire are both pointless imho.

[lucky_]

Since all these nice bits are still in their respective git tree, which kernel and/or radeon driver release will enable all this fun ? Before the end of the year ?
I am about to buy new hardware and want to know if it's worth waiting a couple of months to enjoy it. (I know it's always the same thing but anyway)

[deanjo]

Actually you were mostly right. Sure, you can add a second video-card to your pc, and the nVidia-driver will tell you it's using the cards in SLI, but that's about it. There's practically no performance-gain.

My guess is when Crossfire hits fglrx it will be way superior to nVidias SLI in terms of performance gain, but honestly I don't care. SLI and Crossfire are both pointless imho.

Benchmarks here prove otherwise, SLi is showing nearly double the frame rate.

http://www.phoronix.com/scan.php?page=article&item=860&num=2

[Zhick]

Ok, I didn't know this benchmarks. The last ones I saw showed different numbers. Unfortunately it seems hard to find Linux SLI Benchmarks.
But are there any other games that profit from SLI except Quake 4 (under Linux, of course)?

[deanjo]

Ok, I didn't know this benchmarks. The last ones I saw showed different numbers. Unfortunately it seems hard to find Linux SLI Benchmarks.
But are there any other games that profit from SLI except Quake 4 (under Linux, of course)?

I believe Michael is thinking of doing another revisit to SLi in a future article (more then likely after the 180.X drivers are released in the near future)

[yoshi314]

*celebrates and jumps around*i'd rather like to know, how can we help as ordinary users, at this point.

[bridgman]

Built, test, complain, help the devs troubleshoot, repeat ;)

For radeonhd, if you have a 5xx or earlier card and feel up to running the latest X server please build & run latest X, radeonhd, drm and mesa (say 7.1 RC3 or later). If you have a 6xx or 7xx card you just need to build the latest radeonhd code but hopefully 6xx/7xx accel will start to show up soon so you might as well get used to building everything anyways :D

re: "when will all this stuff show up in distros ?", I imagine the new radeonhd code will make it into most of the distro releases happening this fall (once the next radeonhd release is generated), and kernel modesetting will probably show up first in Fedora.

[yoshi314]

i doubt it's even buildable for a typical user at this point :]

[bridgman]

I guess Tormod's packages will help for Debian-based distros; if you run a different distro that does frequent updates it might be time to start agitating for a new package over the next week or two.

AFAIK the only new twist re: building is that there is a dependency on drm code, but you need that for 3d anyways.

At some point we need to start thinking about DDX, DRM and Meas as one entity released as a set (so you just "update the driver"), but there are both technical challenges and philosophical arguments we need to get through first.

[yoshi314]

if you run a different distro that does frequent updates it might be time to start agitating for a new package over the next week or two.i'm running gentoo and 3d related packages (mesa, kernel drm, libdrm, dri2proto) are straight from git.

also the driver is from git, but the xorg-server is from standard release (1.4.2), and i hope i can have it stay this way.

[TechMage89]

My next card will, without a doubt, be an ATI card. Now I just want to see the support r500 has extended to r600 and r700. Oh, and I really can't wait to see work start on Gallium, too. r500 support is officially terrific now.

[Kano]

Maybe, but that older cards like rv410 (X700 SE) begin to suck even more than before thats no good sign.

[TechMage89]

Well it's probably harder to support oddball cards like the x700 SE b/c it's less likely that devs have them. Which doesn't mean it can't or shouldn't be done, just means you need to pipe up when things break.

[Zhick]

i doubt it's even buildable for a typical user at this point :]
Building everything related to X straight from Git is really easy on the (@Michael) awesome and not the least bit boring Distribution that Gentoo is. Oh how I wish somebody would write an article about Gentoo that does not depict it as boring, ugly and unconfigurable. (http://www.phoronix.com/vr.php?view=12571)

[pheldens]

can somebody explain what this freed up code actually does?

[jlward4th]

This is cool. But last I checked the radeonhd driver didn't support scaling. Once scaling works I can ditch fglrx.

[TechMage89]

@pheldens: This code does kernel modesetting. Meaning you have full modesetting support from kernel init to halt. Also meaning no more suspend/resume issues, because that can be handled cleanly in the kernel. Oh, and you don't have to use X to take adavantage of it.

[bridgman]

New atombios parser :

Last year part of the initial documentation drop was the information and interpreter code required to make use of the command tables in AtomBIOS. The interpreter was written in C and allowed the BIOS code to be written in a portable bytecode language so that BIOS calls could be made without trapping back to 16-bit real mode x86 or running an x86 emulator.

There were some complaints about the code we released initially, mostly (a) compiler warnings because the code was written for our internal development environments not the open source envirotnment, and (b) the way the code was written meant that big changes would be needed to let it be used in the kernel.

Alex ran across this code when we were working with some of the hardware design groups -- it's basically a rewrite of the AtomBIOS interpreter (aka "parser") designed to go in the kernel. The parser in the current radeon and radeonhd drivers has gone through a lot of production testing while the new parser has only gone through development testing, so it's not ready to just drop into radeon and radeonhd as a replacement, but it is useful to help kernel modesetting move ahead.

Kernel modesetting :

Look up Michael's recent article on kernel modesetting (a couple of months ago) for more info, but basically this is the first step to having all graphics control done by a single driver in the kernel, rather than switching back and forth between different drivers when doing vt switching, suspend/resume or even boot up. Incompatibilities between the kernel and X drivers is one of the primary pain points for vt switch and suspend/resume in Linux today; KMS is about having a single driver that everyone uses including X. The other nice thing is that KMS makes it possible for X to run without root privileges, which over time should help to make the whole system more stable. There are conflicting views about KMS, of course -- mostly the usual tradeoff between the problems it solves and the new problems it brings -- but it certainly offers the promise of putting all of the vt switch issues and many of the suspend/resume issues behind us for good.

Quick & dirty accel branch merge into radeonhd master :

This merges in a fresh copy of acceleration code from radeon, which brings full EXA render, textured video support, and allowing 2d and 3d to run at the same time. Anyone with a 690 or 5xx should give it a try.

jlward4th, I think Egbert enabled the scaler in radeonhd a month or two ago, wouldn't hurt to check.

[yoshi314]

KMS is about having a single driver that everyone uses including Xi do hope that KMS drivers will provide a replacement for current framebuffer drivers, like (u)vesafb, etc.

how is that thing going to be worked out?

[TechMage89]

I think it's pretty much guaranteed that there will be console drivers, or else there wouldn't be much point in KMS, would there? Basically, I think the console driver will just be a shim redirecting to the KMS driver.

[yoshi314]

i was rather worried what's going to happen to old fb drivers. are they going to be dropped? what about the generic vesa fb drivers - will there be a generic vesa KMS driver as well?

[some-guy]

I don't think any drivers will disappear, fb drivers still are useful like in boot time, and VESA has to remain as a fallback driver

[TechMage89]

A generic VESA KMS would make a fair amount of sense, but I haven't heard anyone talk about it yet. I must say, good idea yohsi!

[neuron]

anyone got a basic howto on what to build/where patches are etc? And anyone know how stable it is? Is it usable on a day to day system?

[RealNC]

Where to get it depends on your distro. On Gentoo you use the x11 overlay.

I'm using xf86-video-ati from Git on an X1950XT for over a week now without a single crash. It's very promising.

[neuron]

Where to get it depends on your distro. On Gentoo you use the x11 overlay.

I'm using xf86-video-ati from Git on an X1950XT for over a week now without a single crash. It's very promising.

Yeah I'm already on git pretty much everything, but I wanted to try the KMS patch ;)

[bridgman]

So I've just pushed my initial radeon kms code to the "gem-modesetting" branch of the drm git tree.
The corresponding DDX code is in the radeon-gem-ms branch of my personal xf86-video-ati repo.

http://airlied.livejournal.com/

So I think that would be :

DRM - mesa/drm, "gem-modesetting" branch
X driver - users/airlied/xf86-video-ati, "radeon-gem-ms" branch

Dave might pop in and say more but I would consider it highly experimental for now.

[some-guy]

So that means the difference between radeonhd and radeon will be even less now, if I understand correctly, the only *real* differences will be 2D acceleration and video acceleration.

It would be awesome if fglrx could be stripped down to a replacement DRI interface, that way ATi's hidden 3D features could be utilized without their buggy DDX :)

[mattst88]

A generic VESA KMS would make a fair amount of sense, but I haven't heard anyone talk about it yet. I must say, good idea yohsi!

I think you misunderstand what VESA is. It is a common interface for graphics cards.

Kernel Modesetting uses the card's proprietary wake up sequence to initialize it into a state where its full capabilities can be used.

VESA, being the common denominator for graphics cards, is a generic interface for graphics cards.

These two are inherently different, and as I see it, mutually exclusive.

[TechMage89]

No, I don't misunderstand, and no, they are not mutually exclusive.

VESA is a common interface for graphics cards for modesetting as a fallback option. However, there still needs to be a driver to communicate with the graphics card using VESA. Right now, there are separate kernel and X drivers to do the task. This involves duplication of code, slow terminal to X switching, and much of the other ugly stuff involved in this. A VESA KMS module would provide modesetting support for both the framebuffer and for X, and give *some* of the benefits of not having a separate X driver (like for example, not having to run X as root.)

In short, if we want the KMS way to be universal, we need a fallback interface, so that things don't get fouled up if a card is not supported. Basically, we need to make a VESA KMS.