Log in


December 2016
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

airlied [userpic]
radeon-rewrite merged to mesa master + drm pull

So I merged the rewrite of the radeon/r200/r300 to the mesa master today.

On a non-KMS DRI1 system we are hoping these patches are mostly regression free in terms of lockups and possibly fix a fair few lockups thanks to Maciej and Jerome's work.

Of course on a KMS/DRI2 system, this work enables GL on r100-r500 families of radeon cards and we hope to add more features to the ones we gain. We should now at least have FBOs where we never did before (in DRI2/KMS mode).

R600 work is ongoing in a branch still so this announcement has no effect on r600 or above.

I've also sent Linus a drm pull request with all of Intels drm-intel-next branch + all the patches I had sitting in my queue.

Early next week I'll send him the KMS patches for radeon, which will be in the radeon driver but the enable switch will be hidden in staging, while we stabilise it, since its such a huge amount of code. So don't expect miracles out of it anytime soon.

On a PCI ID table comparison Intel KMS have 28 IDs to support, radeon KMS has ~350, granted this code has no memory manager for r600 and up yet (kms code sohuld all be there), so its probably close to 200 GPU variants (+/- 50 for ids not seen in the wild maybe).


Thank you all so much!!

I don't think this applies to my particular card, but let me say a huge thank you for working on Radeon drivers 8D

(No, I'm not upset at all that I got a brand-new computer yesterday and the ATI card inside has been declared "legacy" wrt Linux support... augh)


This "legacy" speak is just marketing jargon for "just works with the Free driver, so there's no need to maintain the proprietary one for that card anymore".

Re: "Legacy"

But it doesn't work just fine with the free one for me. Not yet, anyway. *crosses fingers*


Thank you for all the hard work!


Yeah, thank you! :) Awesome too see the progress. It will be interesting if we will have less problems compared to the intel people. In any case, what you do guys is awesome!


Hi Dave,

great news, looking forward to the kernel inclusion! Could you estimate how much effort/time is needed to fix the XDamage issue with KMS/DRI2 in F11? See https://bugzilla.redhat.com/show_bug.cgi?id=494797 And why does it work with Gnome but not with KDE? It seem to be very mysterious...


Re: XDamage

Try with MESA 7.6. It fixed the issue for me.


great work!!

KMS not working

I've been playing with kernel modesettings for the last 4-5 days.
I'm running Gentoo and I've upgraded mesa, xorg-server (to 1.6) xf86-video-ati to the gem-cs3 branch, tried gallium (with mesa) to no avail. I keep hitting this error:

drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: Searching for BusID pci:0000:01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: drmOpenMinor returns 8
drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
(II) [drm] DRM interface version 1.3
(II) [drm] Could not create SAREA for DRM lock.
(EE) RADEON(0): [dri] DRIGetVersion failed to open the DRM
[dri] Disabling DRI.
(EE) RADEON(0): Kernel modesetting setup failed
(II) UnloadModule: "radeon"
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
Please also check the log file at "/var/log/Xorg.0.log" for additional information.

I have tried:
-> patching the kernel with:
** the patches you published on the kernel mailing list
** manually pulling the drm-linus overlay over the latest official git
-> any possible combination between:
** xorg-server (even live/9999)
** mesa (even different branches master/radeon-rewrite, even though radeon-rewrite has been merged to master)
** xf86-video-ati
** dri2proto package
but nothing worked. I keep hitting that error. If I disable modesettings, DRI gets back working. The Xorg log shows no other errors/warnings.
I didn't know how to contact you, so I thought you'd be reading this =)

Thanks for the hard work,
Neo2 (www.faskatech.net)

Re: KMS not working

Forgot to mention, this happens both on a Mobility Radeon 9600 Pro (M10/R350) on x86 and a Radeon X1900 XT (R580) on amd64, I always get identical output and error.

Thanks again,

Re: KMS not working

You need to revert a problematic patch:


This did the trick for me.

Re: KMS not working

Thanks a lot! I'll try to revert it tomorrow morning and let you know.
I've been stumbling on the commit 6c51d1cfa0a370b48a157163340190cf5fd2346b for a while (which is the one that gets reverted with the one you posted); unfortunately I made the wrong connection between the two. I read in the LKML that it caused the problem and thus got reverted with the commit you mentioned, but now it seems that even Radeon code needs this, (Intel code did already as far as I know). Guess this has to do with old code vs. new code.


Re: KMS not working

Now working! Had to switch to the ~glisse xf86-video-ati git repo though.. otherwise it would throw:
[drm:radeon_cp_getparam_kms] *ERROR* invalid ioctl with kms radeon_cp_getparam_kms
Still many thanks ;-)


ps: sorry for last post's misspellings

Re: KMS not working


I was surprised to see it working almost flawlessly (after I managed to get the correct git trees and patches). Also nice to see how glxgears runs inside the window under Compiz correctly now.

Just out of curiosity, are you also seeing these: (on a T60 here)

- suspend/resume works, but the screen is messed up after resuming
(vertical lines in all kinds of colors, can switch between X and console,
but the lines don't go away, they just change)
- In compiz, the vblank interrupt doesn't seem to work (when I turn vblank
sync on, I get a screen update frequency of under 1Hz)
- without the latter, the screen updating is smooth most of the time, but
you get occasional small hangs
- Xv is broken, the texture is scaled in a wrong way, it zooms into the
upper left corner. Seems to be an artifact of the xf86-video-ati driver
this is branched off, as it also happens with DRI1 in a regular non-KMS
setup. (under compiz in both cases)


Re: KMS not working

Hi Christophe.
Well, I haven't tested suspend/resume, but I guess it doesn't work that well. Just few minutes ago I tried to resume my laptop after auto-suspend (x86 platform) and it just presented a blank screen (had to hard-reset).
I don't use compiz and thus I can't make comparisons about that. I can say that screen updating is *very* smooth when compared to non-KMS non-TTM code (good old Radeon DRM 1.30). The gain is visible especially when scrolling content-rich web pages.
I have never used Vsync, and I think I can only set it up with EXA in xorg.conf. I've been reading some posts about Gallium and the xorg architecure saying that mesa/xorg are not yet ready for an efficient Vsync solution, so I'll stick without that.
About Xv, if you mean "video playing" with it, it doesn't work that well either. I've been playing both a downloaded sample avi video with VLC and a youtube video. Conclusions:
-> VLC video does NOT work well. Image gets cropped and zoomed and the upper left corner gets displayed (like yours I guess). This happens when playing both from a resized window and full screen
-> Youtube video works perfectly (at this point I guess it doesn't use or rely on Xv) both from window and full screen. The video looks sharper and more fluid than has ever been possible with the old code though (especially in full screen mode).
On the amd64 platform instead, I've seen a lot of crashes and garbage, but that is probably due to mesa and the card being an R580. Anyway, I'm recompiling the whole system with sane CFLAGS. I compiled it with gcc-4.4 and graphite system-wide and I suspect it introduces some lag and non-obvious easy-to-trigger bugs. Will let you know tomorrow, when the system has ended the recompile.
On both platforms, the console mode is near to perfection: fast switch, sharp fonts, very fast scrolling. I'm currently playing with dynclks but no luck so far =)


Re: KMS not working

Alright, tested with a sane system and it doesn't work (R580 on amd64). The GPU keeps getting resetted after timeouts.
Anyway, I'll try to follow Dave's new instructions from the latest post this evening and see if it works. Probably some piece of my userspace code is still not up2date.


r300 & ppc

thanks for your hard work, it really is much appreciated.
kms works just fine now on my eeepc f.ex. and i´m going to try it out on my old powerbook which has a radeon 9600. Are there any limitations i should be aware off ? Is it even expected to run on non x86 arches at this point ?

thanks !