Log in


March 2015
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]
whats in drm-radeon-testing?

I'll try and post these regularly when I make major additions/removals.

drm-radeon-testing is the cutting edge KMS radeon branch, it is going to be rebased and things will be added/removed as they are worked on by developers. So you can base patches on it but you should talk to the developer who owns the area first.

git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-radeon-testing

I've just pushed a rebased tree now with the following:

latest i2c algo + hw i2c engine code + all fixes squashed: This adds support for hw i2c engines found on radeons and
exposes them + sw i2c buses to userspace so i2c tools can use them. (agd5f).

pll algorithm reworking + quirks: cleans up the code to allow for the selection of the old pll algorithm on some hardware. (agd5f)

pm support so far: Adds all the current PM patches - just does engine reclocking so far using the power tables from the BIOS. (Zajec/agd5f)

Evergreen (Radeon HD 5xxx) support: basic KMS support for the evergreen range of devices - no irqs or accel yet. (agd5f)

radeon unlocked ioctl support (airlied)

bad CS recording (glisse)

misc cleanups/fixes - Dell/Sun server support ported from userspace hopefully.

The tree did contain Jerome's r600 CS checker but I've dropped it for now at his request as he has newer patches
in testing.

Is there a timeline for R300g as a default?

The work that CorbinS is doing to get OpenGL 2.0 on older radeon cards seems to be moving along rapidly. Are there any plans to switch to it by default in Fedora? It would be nice to be in the position where all ATI cards were OGL2 out of the box...

Keep up the good work! I remember when getting a graphics card to work in Linux was a WOW moment. I never dreamt that 3d would be a possibility :)

Re: Is there a timeline for R300g as a default?

not yet, when its readier, i've been trying to give it some focus to make it as fast as clasicc and stuff, but gallium is has still some twisty passages to get lost in .

weird GPU resets

Hi Dave,
first of all thanks for your hard work.
I've been using kms since about July 2009 with the latest git tree from the linux kernel.
I have always experienced this weird error:
[drm:radeon_fence_wait] *ERROR* fence(ffff8801fd1b9ec0:0x00002023) 510ms timeout going to reset GPU
[drm] CP reset succeed (RBBM_STATUS=0x10000140)
[drm] radeon: cp idle (0x10000000)
[drm] radeon: ring at 0x0000000020000000
[drm] ring test succeeded in 2 usecs
[drm] GPU reset succeed (RBBM_STATUS=0x10000140)
[drm:radeon_fence_wait] *ERROR* fence(ffff8801fd1b9ec0:0x00002023) 520ms timeout going to reset GPU
[drm:radeon_fence_wait] *ERROR* last signaled fence(0x00002023)
going on for ever and ever as long as I kill kde4 or the machine deadlocks. What changes between the various log entries are only the addresses of the fences; timeouts, ring test and RBBM_STATUS keep showing the same values.
Two days ago I installed kde 4.4.0 and the machine became unusable. Before that the machine used to hang occasionally (once every 3-4 days, randomly), allowing me to keep kms and blame it every now and then for the lockup. But since Tuesday it hangs every time I try to start KDE. It either crashes in a moment or it takes just few minutes, the time needed to change some settings. The card is a X1900 XT and has a R580 chip with 512mb memory.
I tried pulling the latest drm-radeon-testing (along with drm-linus and drm-next to avoid merge conflicts) but nothing changed. I'm running libdrm, mesa and xf86-video-ati from latest git.
Is there any known workaround? I can provide more info and help debugging. If you do a quick search with google you'll see that is a known problem even on binary based distributions (Fedora and Ubuntu the ones I read of).
One final question, I saw you're answering bug reports both on freedesktop and the kernel bugzilla, where should I file it?
In the meantime I'll stick with non-kms rendering.