Open-Source 2D, 3D For ATI Radeon HD 5000 Series GPUs

[allquixotic]

OK, I got the firmware to load. I guess that the firmware got excluded from the built-in kernel somehow, because it was trying to bring up the radeon driver before the ext4 was initialized... I made drm and radeon build as modules, and the firmware loads.

However, I'm still stuck with the shadowfb, and I see no indication why in terms of the kernel. It would appear that the kernel is operating correctly.

So then the userspace somehow is acting up. I'll ask on #radeon.

[DuSTman]

Well the point is that shadowfb is doing almost nothing; only blitting and drawing some shit on RAM and then sending it happily to the framebuffer.

Now if you'd be doing more than just this crap it would be more efficient per time to send it all over tot the graphics card, which takes time, and let the GPU handle all that stuff.

Kindof. The CPU has much less latency to system RAM than it does to gfx card RAM - so there's less latency for the CPU to rasterise graphics to main memory than to send the command to the GPU. The GPU can draw much faster once it's recieved the commands..

Anyway, this means that for small writes(such as drawing an icon) the CPU can probably perform that operation in system RAM in less time than it would take to send that task to the GPU. Large tasks, (drawing large areas, and with complex shaders) the GPU's much higher speed at these tasks will more than compensate.

In cairo benchmarks, the evergreen_accel gets at best half what my CPU does in shadowfb mode. I expect this will improve a bit once the drivers get beaten on a bit more.

[allquixotic]

A few things:

1. I got out of shadowfb mode. Turns out I was being stupid and didn't really have the evergreen_accel branch compiling. I had to rerun autogen.sh to get configure to generate Makefiles that included the evergreen translation units. Grr.

2. Gnome/compiz compositing crashes when you minimize windows, but Kwin doesn't if you tell it to always keep thumbnails in the control center (it's the option that says "Breaks minimization"). Probably some issue related to evicting EXA pixmaps out of VRAM and into (?) system RAM when they are minimized. IMHO this is unnecessary on cards with as much VRAM as mine (1892 MB); more effort should be made to actually use the VRAM that is available. But that is neither here nor there.

3. Workaround for corrupt mouse cursor:
Edit your xorg.conf, under the Driver "radeon" section, and add

Option "RenderAccel" "off"

This will give you a working mouse cursor, but obviously anything that uses the XRender extension will either be very slow, or won't work. Mouse cursor performance seems unaffected, as it's still using a hardware cursor.

So now I've got EXA and a compositing manager that is relatively stable on top of a HD5970. I'd still like to see the driver stabilize, but the basic tech is visibly starting to work.

[rohcQaH]

I've done some more detailed test in addition to my last post.

radeon, today's git:
mesa reverted to 7.8.2, export LIBGL_ALWAYS_SOFTWARE=1

• glxgears works without corruption
• xv doesn't work at all, there's nothing but slight colourful flickering in the whole window
• screenshots I take (both ksnapshot and import -window root file.png) are still corrupted (see last post for an example)
• kde3 still has the same corruption as before, it's not related to mesa (kde3 doesn't use opengl much, anyway)

same as before, but added to my xorg.conf: Option "RenderAccel" "off":

• no changes with glxgears and xv
• screenshots I take with import are still corrupted, ksnapshot started to work though.
• corruption in kde3 is gone, even with composition (it's not opengl-based, anyway)
• more extensive tests revealed corruption in Seamonkey, but not in firefox or other GTK-apps I tested
• flash (firefox) worked right until I clicked the "fullscreen" button, let's blame flash for that

If I had to take a wild guess, reading from the framebuffer is broken in some way. Not just because of the screenshots, but also because most pseudo-transparency effects (yakuake, crystal window decorations) are corrupted.
On the other hand, compositing and true transparency effect work fine, so vram->vram blits appear to work.
The mouse pointer and some icons are displayed wrong, too. The corruption looks similar to the screenshot/transparency bugs, so it may or may not have the same root cause.


xv worked fine last week (until x crashed), should I try to bisect?

reinstalled mesa master (today), enabled hardware 3d.

• xv still broken
• glxgears still messes with parts of the video memory it shouldn't mess with, resulting in corruption in the form of horizontal lines (not neccessarily in the framebuffer, but this time in my wallpaper's pixmap).
  With RenderAccel off, glxgears appeared to work fine, save for some horizontal red lines that appeared in glxgear's window from time to time.
• neverball still doesn't start with r600 (as mentioned in my last post)
• kde 4.5: seems to work fine with compositing disabled, had corruption with XRender compositing (even with RenderAccel off), kwin4 crashes immediately when opengl compositing is active, each time this appears in dmesg:
  

  [ 3877.649234] radeon 0000:02:00.0: forbidden register 0x00009508 at 10
  [ 3877.649237] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

in other words, as far as I'm concerned, r600's status is "glxgears barely works" :/

[allquixotic]

I've done some more detailed test in addition to my last post.

radeon, today's git:
mesa reverted to 7.8.2, export LIBGL_ALWAYS_SOFTWARE=1

• glxgears works without corruption
• xv doesn't work at all, there's nothing but slight colourful flickering in the whole window
• screenshots I take (both ksnapshot and import -window root file.png) are still corrupted (see last post for an example)
• kde3 still has the same corruption as before, it's not related to mesa (kde3 doesn't use opengl much, anyway)

same as before, but added to my xorg.conf: Option "RenderAccel" "off":

• no changes with glxgears and xv
• screenshots I take with import are still corrupted, ksnapshot started to work though.
• corruption in kde3 is gone, even with composition (it's not opengl-based, anyway)
• more extensive tests revealed corruption in Seamonkey, but not in firefox or other GTK-apps I tested
• flash (firefox) worked right until I clicked the "fullscreen" button, let's blame flash for that

If I had to take a wild guess, reading from the framebuffer is broken in some way. Not just because of the screenshots, but also because most pseudo-transparency effects (yakuake, crystal window decorations) are corrupted.
On the other hand, compositing and true transparency effect work fine, so vram->vram blits appear to work.
The mouse pointer and some icons are displayed wrong, too. The corruption looks similar to the screenshot/transparency bugs, so it may or may not have the same root cause.


xv worked fine last week (until x crashed), should I try to bisect?

reinstalled mesa master (today), enabled hardware 3d.

• xv still broken
• glxgears still messes with parts of the video memory it shouldn't mess with, resulting in corruption in the form of horizontal lines (not neccessarily in the framebuffer, but this time in my wallpaper's pixmap).
  With RenderAccel off, glxgears appeared to work fine, save for some horizontal red lines that appeared in glxgear's window from time to time.
• neverball still doesn't start with r600 (as mentioned in my last post)
• kde 4.5: seems to work fine with compositing disabled, had corruption with XRender compositing (even with RenderAccel off), kwin4 crashes immediately when opengl compositing is active, each time this appears in dmesg:
  

  [ 3877.649234] radeon 0000:02:00.0: forbidden register 0x00009508 at 10
  [ 3877.649237] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

in other words, as far as I'm concerned, r600's status is "glxgears barely works" :/

It needs a lot of work still. I may be seeing bugs in unrelated components like the kernel or the X server, but I can't even get the driver to load up DRI2 today. It just falls back to software without any explanation as to why.

[nanonyme]

Very much sounds like your kernel and Mesa aren't compatible with each other. "forbidden register" is a good hint of this. There's security functionality in kernel DRM, afaik mostly written by glisse, that causes that kind of stuff to be outputted. If the register should be usable, updating kernel might fix it. If not, updating Mesa might fix it. But since you don't know, could as well update both.

[rohcQaH]

I was using the latest mesa git and the latest stable kernel (2.6.35). It's supposed to work with .35, so I don't want to risk further trouble by using a .36-RC-kernel.

Besides, the trouble in 2d-land certainly isn't related to mesa.

[nanonyme]

Have you already filed a bug on your problems, btw?

[rohcQaH]

I hijacked this report for xv:

https://bugs.freedesktop.org/show_bug.cgi?id=29788

I tried to write a simple testcase that'd show the gfx corruption I mentioned, but after stripping imagemagick down as far as I could, the result was an uncorrupted screenshot. oops.

btw:

It seems that I have to run fglrx first to set the GPU to a sane state before I can use any of the open source acceleration stuff.

hasn't been a problem for me, the OSS drivers work equally well (or not well) after a cold boot.

[nanonyme]

How about running it with Valgrind if that segfault relates to your case also?