Bug 59703 - radeonsi & glamor: No acceleration
radeonsi & glamor: No acceleration
Status: RESOLVED INVALID
Product: xorg
Classification: Unclassified
Component: Driver/Radeon
git
x86-64 (AMD64) Linux (All)
: medium normal
Assigned To: xf86-video-ati maintainers
Xorg Project Team
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-22 09:24 UTC by Ralf-Peter Rohbeck
Modified: 2013-12-02 18:48 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
xorg.conf (11.60 KB, text/plain)
2013-01-22 09:24 UTC, Ralf-Peter Rohbeck
no flags Details
Xorg.0.log (40.11 KB, text/plain)
2013-01-22 09:24 UTC, Ralf-Peter Rohbeck
no flags Details
Build script (6.87 KB, text/plain)
2013-01-22 09:25 UTC, Ralf-Peter Rohbeck
no flags Details
Screen shot (456.85 KB, image/png)
2013-01-23 11:05 UTC, Ralf-Peter Rohbeck
no flags Details
Latest build script, this worked (7.41 KB, text/plain)
2013-01-23 11:17 UTC, Ralf-Peter Rohbeck
no flags Details
Current xorg.conf (5.24 KB, text/plain)
2013-01-23 11:17 UTC, Ralf-Peter Rohbeck
no flags Details
Slightly incorrect semitransparent window decorations (136.34 KB, image/png)
2013-03-19 06:59 UTC, Ralf-Peter Rohbeck
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf-Peter Rohbeck 2013-01-22 09:24:21 UTC
Created attachment 73435 [details]
xorg.conf

I tried to build the entire stack with radeonsi according to the instructions on various wiki pages but It keeps telling me
[   593.260] (II) RADEON(0): Acceleration disabled

This what I do (PREFIX=/opt/xorg):

- Build and install latest (3.8rc1 earlier, now 3.8rc4) kernel from git://people.freedesktop.org/~airlied/linux, origin/drm-next branch

- Download/build/install LLVM from git://people.freedesktop.org/~tstellar/llvm with --prefix=/usr/local --enable-experimental-targets=R600 --enable-optimized --cache-file=/dev/null --srcdir=.

- Download/build/install whole stack with git://anongit.freedesktop.org/git/xorg/util/modular with --prefix=$PREFIX --enable-gallium-radeon --with-state-trackers=dri,glx --with-dri-driverdir=$PREFIX/lib/dri --with-egl-platforms=x11,drm --with-gallium-drivers=swrast,radeonsi --enable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers=radeon,swrast --enable-glamor

- Download/build/install xserver from http://ftp.x.org/pub/individual/xserver/xorg-server-1.11.4.tar.bz2 with --prefix=$PREFIX --enable-glx-tls --enable-xorg --disable-dmx --disable-xvfb --disable-xnest --disable-xwin

- Download/build/install drm from git://anongit.freedesktop.org/git/mesa/drm with --prefix=$PREFIX

- Download/build/install mesa from git://anongit.freedesktop.org/mesa/mesa with --prefix=$PREFIX --with-dri-driverdir=$PREFIX/lib/dri --with-egl-platforms=x11,drm --with-gallium-drivers=swrast,r300,r600,radeonsi --enable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers=radeon,swrast

- Add symlinks to /usr/local/lib/dri/radeonsi_dri.so and /usr/local/lib/libGL.so that seem to be needed (looks like bugs to me - should be loaded from $PREFIX/lib)

- Download/build/install glamor from git://anongit.freedesktop.org/git/xorg/driver/glamor with --prefix=$PREFIX --enable-glx-tls

- Download/build/install xf86-video-ati from git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati with --prefix=$PREFIX --enable-gallium-radeon --with-egl-platforms=x11,drm --enable-glamor

Finally I set up /etc/environment with LIBGL_DRIVERS_PATH=$PREFIX/lib/dri/ and /etc/ld.so.conf.d/a-local-xorg.conf with $PREFIX/lib and run ldconfig.

xorg.conf, Xorg.0.log and my build script attached.

Help!

Thanks,
Ralf-Peter
Comment 1 Ralf-Peter Rohbeck 2013-01-22 09:24:52 UTC
Created attachment 73436 [details]
Xorg.0.log
Comment 2 Ralf-Peter Rohbeck 2013-01-22 09:25:30 UTC
Created attachment 73437 [details]
Build script
Comment 3 Ralf-Peter Rohbeck 2013-01-22 09:29:05 UTC
P.S. HD7850 2GB on Debian wheezy amd64 with KDE. I changed /etc/kde4/kdm/kdmrc to have
ServerCmd=/opt/xorg/bin/X -verbose 9 -logverbose 9 -configdir /opt/xorg/share/X11/xorg.conf.d
Comment 4 Ralf-Peter Rohbeck 2013-01-22 10:30:37 UTC
(In reply to comment #1)
> Created attachment 73436 [details]
> Xorg.0.log

Oops, I just noticed that the driver didn't load at all in this case. Will try again tomorrow.
Comment 5 Michel Dänzer 2013-01-22 11:11:11 UTC
The Xorg.0.log you posted in the Phoronix forum didn't have any trace of Option "AccelMethod", meaning your Section "Device" didn't get picked up. Have you tried renaming the xorg.conf.d/ file containing it to *.conf, or just putting the Section "Device" into a good old-fashioned xorg.conf file?
Comment 6 John Bridgman 2013-01-22 11:59:15 UTC
I noticed the following in your xorg log :

55.506] (II) [KMS] drm report modesetting isn't supported.

Can you post dmesg output as well ?
Comment 7 John Bridgman 2013-01-22 15:09:50 UTC
Never mind, looks like you already noticed the KMS startup problem (#5).
Comment 8 Ralf-Peter Rohbeck 2013-01-23 11:04:24 UTC
OK one crash and one hang with fglrx 13.1 today gave me a lot of incentive to work some more on this.
I got it to work! It seems that the root cause was that the old X server didn't pick up the config files from /opt/xorg/share/X11/xorg.conf.d correctly. Once I cat'd them all to /etc/X11/xorg.conf and got rid of the -configdir argument for X things became much better. Thanks all! You got me on the right track.

Observations:
The whole thing hung hard immediately with Dave Airlie's 3.8rc4 drm-next kernel but with 3.7 it works mostly.

DRM/KMS with 2560x1440 monitors on DP->DVI adapters doesn't work correctly. The monitors were detected with the wrong resolution (1024x768) even after I hardwired them on the kernel command line with video=DP-1:2560x1440-24@60e video=DP-2:2560x1440-24@60e.

The only thing that worked was to hardwire the modeline in xorg.conf but xrandr -q still thinks they can do other modes than 2560x1440 (they don't):

DisplayPort-0 connected 1440x2560+3360+0 right (normal left inverted right x axis y axis) 0mm x 0mm
   2560x1440      60.0*+
   1024x768       60.0  
   800x600        60.3     56.2  
   848x480        60.0  
   640x480        59.9  

However the monitor detection/mode switching code in the Atom BIOS is broken in general for DP outputs. Not even the BIOS switches modes correctly when these monitors are connected. I had a long and fruitless exchange with AMD tech support about this. Now the monitors are still not detected reliably but switching to a text console and back gets them all up after a couple of tries.

KDE decorations don't look quite right (default theme, XRender or OpenGL.) I'll attach a screenshot.

Every now and then the display freezes for a moment. During that time the migration process is very busy, often with over 200% CPU and several threads. This can be triggered by switching KDE desktop effects on/off (Shift-Alt-F12.) Doing that also leaves some garbage on the screen.

Other than that, I have messed around for a while and haven't seen a crash yet. So far so good :)
Comment 9 Ralf-Peter Rohbeck 2013-01-23 11:05:27 UTC
Created attachment 73508 [details]
Screen shot
Comment 10 Ralf-Peter Rohbeck 2013-01-23 11:17:20 UTC
Created attachment 73509 [details]
Latest build script, this worked
Comment 11 Ralf-Peter Rohbeck 2013-01-23 11:17:48 UTC
Created attachment 73510 [details]
Current xorg.conf
Comment 12 Alex Deucher 2013-01-23 14:01:49 UTC
(In reply to comment #8)
> 
> DRM/KMS with 2560x1440 monitors on DP->DVI adapters doesn't work correctly.
> The monitors were detected with the wrong resolution (1024x768) even after I
> hardwired them on the kernel command line with video=DP-1:2560x1440-24@60e
> video=DP-2:2560x1440-24@60e.

This is material for another bug report.

> 
> However the monitor detection/mode switching code in the Atom BIOS is broken
> in general for DP outputs. Not even the BIOS switches modes correctly when
> these monitors are connected. I had a long and fruitless exchange with AMD
> tech support about this. Now the monitors are still not detected reliably
> but switching to a text console and back gets them all up after a couple of
> tries.

What kind of DP->DVI adapters are you using?  Make sure they are active adapters that support dual link since your monitors require dual-link DVI and passive DP->DVI adapters only support single link.  Also, most active adapters also only support single link DVI; you need to make sure you specifically got dual-link capable active adapters.  If they are active adapters, make sure they are properly powered.  You might also want to try alternate adapters as a lot of cheap ones don't work very well.
Comment 13 Michel Dänzer 2013-01-23 16:40:15 UTC
(In reply to comment #8)
> The whole thing hung hard immediately with Dave Airlie's 3.8rc4 drm-next
> kernel but with 3.7 it works mostly.

How about the latest drm-fixes tree? If it still happens with that, can you bisect?


> KDE decorations don't look quite right (default theme, XRender or OpenGL.)

I can't seem to reproduce this.

Did you change any decoration options from the default?

Which Git commits of libdrm, Mesa, glamor and xf86-video-ati are you currently using?


> Every now and then the display freezes for a moment. During that time the
> migration process is very busy, often with over 200% CPU and several
> threads.

Can't seem to reproduce this either. AFAICT the migration/%d kernel threads are related to stopping CPU cores, so this doesn't sound directly related to the graphics drivers.


> This can be triggered by switching KDE desktop effects on/off
> (Shift-Alt-F12.) Doing that also leaves some garbage on the screen.

Leaves garbage where? The only garbage I've noticed so far is when a window is dimmed due to a modal dialogue, and only when using OpenGL for effects. That's probably a radeonsi driver issue.
Comment 14 Ralf-Peter Rohbeck 2013-01-23 16:54:05 UTC
(In reply to comment #12)
> This is material for another bug report.
Where should I report this? Going through AMD support was fruitless and this is clearly a BIOS bug. Does it belong here, or http://ati.cchtml.com? Is the latter actually used by anyone at AMD?

> What kind of DP->DVI adapters are you using?
Accell B087B-007B, an improved version of the approved one for Eyefinity.
Comment 15 Alex Deucher 2013-01-23 16:59:03 UTC
(In reply to comment #14)
> (In reply to comment #12)
> > This is material for another bug report.
> Where should I report this? Going through AMD support was fruitless and this
> is clearly a BIOS bug. Does it belong here, or http://ati.cchtml.com? Is the
> latter actually used by anyone at AMD?

For the open source driver, use this bugzilla.

> 
> > What kind of DP->DVI adapters are you using?
> Accell B087B-007B, an improved version of the approved one for Eyefinity.

Ok.
Comment 16 Ralf-Peter Rohbeck 2013-01-24 21:29:36 UTC
(In reply to comment #13)
> > KDE decorations don't look quite right (default theme, XRender or OpenGL.)
> 
> I can't seem to reproduce this.
> 
> Did you change any decoration options from the default?
I haven't looked into this any deeper yet, but an observation:
I just used NX (nomachine debian packages) to log into a box running bog standard Debian wheezy (amd64/KDE) and I saw the white vertical lines in konsole window titles too so it seems that it's just the gradient that doesn't come out right.
I confirmed that by running konsole locally and resizing it: The pattern of stripes changes with the width of the title bar. The effect is best seen with a black background.
Comment 17 Ralf-Peter Rohbeck 2013-01-24 22:13:32 UTC
(In reply to comment #13)
> Leaves garbage where? The only garbage I've noticed so far is when a window
> is dimmed due to a modal dialogue, and only when using OpenGL for effects.
> That's probably a radeonsi driver issue.

This and the window decoration weirdness both seem so happen with semi-transparent UI elements. The konsole window title is also semi-transparent.
Comment 18 Ralf-Peter Rohbeck 2013-03-06 01:51:42 UTC
The occasional hiccups with a migration thread running are gone after my latest update (rebuilt everything from git) with the Debian 3.8-1~experimental.1 kernel.

Right now I'm quite happy - the only issue is the slight corruption with semitransparent KDE GUI elements (easily seen when opening a file in e.g. kate) but since that's only temporary it doesn't bother me too much.
Comment 19 cybjit 2013-03-06 19:10:10 UTC
(In reply to comment #9)
> Created attachment 73508 [details]
> Screen shot

I have this graphical glitch if I choose Qt graphics system: Native. With Qt graphics system: Raster it goes away.
Comment 20 Ralf-Peter Rohbeck 2013-03-11 04:29:05 UTC
(In reply to comment #18)
> The occasional hiccups with a migration thread running are gone after my
> latest update (rebuilt everything from git) with the Debian
> 3.8-1~experimental.1 kernel.

This is kernel dependent:  Happens with Debian 3.7.3-1~experimental.1 but not with 3.8-1~experimental.1.
Comment 21 Ralf-Peter Rohbeck 2013-03-19 06:57:27 UTC
(In reply to comment #18)
> Right now I'm quite happy - the only issue is the slight corruption with
> semitransparent KDE GUI elements (easily seen when opening a file in e.g.
> kate) but since that's only temporary it doesn't bother me too much.

The corruption is gone with Dave Airlie's 3.9.0-rc2+ kernel. There's some slightly incorrect rendering left with semitransparent window decorations in KDE (OpenGL or Xrender desktop effects.) See the screenshot.
Comment 22 Ralf-Peter Rohbeck 2013-03-19 06:59:08 UTC
Created attachment 76739 [details]
Slightly incorrect semitransparent window decorations
Comment 23 Michel Dänzer 2013-03-19 08:26:54 UTC
Ralf-Peter, remember you resolved this report two months ago. :)

Any remaining issues should be tracked in separate reports.
Comment 24 Ralf-Peter Rohbeck 2013-03-19 08:33:33 UTC
(In reply to comment #23)
I'm not complaining - just informing you of progress :)

My last build didn't work so I'm not up to date. When I get a new build working and it's still there I'll open another bug.
Comment 25 Ralf-Peter Rohbeck 2013-03-19 08:39:59 UTC
(In reply to comment #24)
P.S. Another reason is that I'm running a Franken-Debian with libdrm-radeon1 2.4.42-0ubuntu1 right now because experimental still has 2.4.40. Waiting for an update...
Comment 26 Michel Dänzer 2013-03-22 16:42:26 UTC
(In reply to comment #19)
> I have this graphical glitch if I choose Qt graphics system: Native. With Qt
> graphics system: Raster it goes away.

Where can I choose that?
Comment 27 cybjit 2013-03-22 17:53:16 UTC
(In reply to comment #26)
> (In reply to comment #19)
> > I have this graphical glitch if I choose Qt graphics system: Native. With Qt
> > graphics system: Raster it goes away.
> 
> Where can I choose that?

In Kubuntu it is System Settings / Desktop Effects / Advanced