Radeon KMS Code Goes Up For Review

[phoronix]

Phoronix: Radeon KMS Code Goes Up For Review

Less than a day after the TTM memory management code was pushed out for review, the ATI kernel mode-setting driver is now getting ready for entrance into the Linux kernel too. Jerome Glisse has now announced on the kernel mailing list (as well as the DRI development list) that the Radeon KMS code is ready for review. This code, which is dependent upon the just-proposed TTM memory manager, places the video mode-setting into the Linux kernel and trails the Intel KMS driver, which entered the Linux 2.6.29 kernel...

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

[bulletxt]

I always thought my AMD card wouldn't work full featured before the end of 2010. And something is telling me it can even get worse. The problem is, what's the point of all this? Isn't world ending 23 december 2012? :D

[Darkfire Fox]

I always thought my AMD card wouldn't work full featured before the end of 2010. And something is telling me it can even get worse. The problem is, what's the point of all this? Isn't world ending 23 december 2012? :D

Bah, only lemmings believe such things! :D

On a more serious note, I wonder what that "potential security flaw" is?

[bulletxt]

Bah, only lemmings believe such things! :D

On a more serious note, I wonder what that "potential security flaw" is?


Maybe gain root access through an exploit in the driver

[chithanh]

On a more serious note, I wonder what that "potential security flaw" is?The issue is described in the announcement which is linked from the Phoronix article. Basically it is accessing memory of other processes.

[Darkfire Fox]

The issue is described in the announcement which is linked from the Phoronix article.

D'oh! :rolleyes:

[RealNC]

Haha, this driver will be marked "crap" (others use the word "staging"). Did the Intel driver ever belong to "crap"? :D

[madman2k]

Haha, this driver will be marked "crap" (others use the word "staging").
not quite: http://kerneltrap.org/Linux/Introducing_the_Linux_Staging_Tree

note that the old memory model did not do any guarantees at all. So its just about a new feature to be tested out.

[RealNC]

Uhm, I'm referring to the fact that "crap" is used to describe the staging tree :P

See http://lwn.net/Articles/300890

[MùPùF]

Just a quick question :

Will I get DRI2 with the 2.6.31 or will radeon still lack of something ?

I just want to make sure before celebrating :d

[smitty3268]

Just a quick question :

Will I get DRI2 with the 2.6.31 or will radeon still lack of something ?

I just want to make sure before celebrating :d

No, you need more. http://jglisse.livejournal.com/ has a post about how to get everything running, although i'm not sure if that's still accurate or not. The kernel stuff would be taken care of, but that leaves DRM, Mesa, and the xf86-video-ati driver that need to be compiled from source. Hopefully all those branches can be merged into master by the time 2.6.31 is out. You'll also need at least X-Server 1.6 if you don't already have it.

The kernel is a big chunk, though, that all the other stuff relies on so getting this code in is an important step.

[MùPùF]

No, you need more. http://jglisse.livejournal.com/ has a post about how to get everything running, although i'm not sure if that's still accurate or not. The kernel stuff would be taken care of, but that leaves DRM, Mesa, and the xf86-video-ati driver that need to be compiled from source. Hopefully all those branches can be merged into master by the time 2.6.31 is out. You'll also need at least X-Server 1.6 if you don't already have it.

The kernel is a big chunk, though, that all the other stuff relies on so getting this code in is an important step.

Sorry, I mean't on the kernel side, I already have the latest libdrm, xf86-video-ati and I use the radeon-rewrite branch of mesa.

I already tried what Jerome Glisse proposed on his blog but it always lead to a system crash. Fedora 11 is broken too, I'll wait for 2.6.31-rc2 to try KMS out ! Hope everything will be OK.

Thanks

[Veerappan]

I've been using the radeon-rewrite/radeon-gem-cs3/drm-next-radeon branches for a few weeks now (pretty much since John Glisse posted his little how-to), and I've been very impressed with the code so far. I've had to patch the X driver to get Xv working correctly (thanks agd5f), and suspend to ram doesn't resume correctly (x300 mobility), but otherwise it's pretty good. I've been considering trying to get involved in working on the power management code, but first I need to do a lot of studying of the existing codebase.. :)

I've been recently attempting to throw the phoronix test suite against the mesa drivers, but that hasn't worked out so well... running the PTS Mesa suite executes fine, albeit slowly, but before the suite completes I've gotten hard locks (SysRq doesn't work... probably the video chip begging for mercy).

[nanonyme]

Basically it is accessing memory of other processes."you can (with some difficulties) theoretically write or read GPU object of other process, i am pretty confident that you cannot access system ram beside one allocated for GPU objec" to be exact, quote was from glisse

[highlandsun]

So just to confirm, what impact does this have on r600/r700? I assume that fbcon will work, and if we use only that (no X) then we should get stable suspend/resume. But with X, will things continue unchanged, or will they be particularly broken? And if I only care about 2D / Xv and not 3D, will it have any impact?

[bridgman]

Should be no impact on 6xx and up; KMS should be disabled by default, and fbcon etc.. should go and bang on the hardware like they always did. The X driver would continue to do userspace modesetting.

That's the theory anyways ;)

[highlandsun]

Cool, thanks. Then I'm not going to bother recompiling my latest git pulls...