Radeon KMS Code Goes Up For Review

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

[MuPuF]

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