Created attachment 31493 [details]
xorg.conf

Overview:  Enabling OpenGL support in apps while using combination of radeonhd with RV770 GPU leads to massive screen corruption.  It's likely that this is a very hardware-specific issue -- see reference to fdo bug #24301 in "Additional information" section below.  Originally this bug was shared by radeon as well as radeonhd, but has been fixed in xf86-video-ati by Alex Deucher (commit 5f84636...), so it now is present in radeonhd only.


Steps to reproduce:  I've been using two apps to test OpenGL:  'prboom' and 'dosbox'.  (I believe that running any app using OpenGL would result in the same massive rendering corruption.)

prboom:  running 'prboom -vidmode gl' enables OpenGL support, resulting in corruption.  (Running 'prboom' without "-vidmode gl" option disables OpenGL, and rendering is fine.)

dosbox:  graphics output mode is controlled by ~/.dosboxrc, in the section called "[sdl]", and using the option "output=opengl" enables OpenGL support.  (Setting this to other output modes, such as "output=overlay", disables OpenGL in DOSBox and results in perfect rendering.)


Actual results:

prboom:  running prboom with OpenGL enabled results in massive screen corruption.  The game does not crash, but all surfaces and enemies are rendered in a garbled fashion.  Essentially unplayable, unless you want to take an "acid trip" without the LSD.

dosbox:  Running an old DOS game (I've been using Warlords 2) with OpenGL enabled results in worse corruption than with 'prboom', and is totally unusable.  DOSBox is not crashed, and the game's keyboard shortcuts are working, but you cannot see anything at all except the unchanging, corrupt graphics.

Both test apps spam my dmesg and kern.log files with this message when running with OpenGL enabled:

    [drm:r600_cp_dispatch_texture] *ERROR* Invalid destination offset


Expected results:  both apps should render the games without corrupting the graphics and with all of the benefits OpenGL has to offer (acceleration, superior rendering quality, etc.).


System info:
GPU:
    GIGABYTE GV-R485MC-1GI Radeon HD 4850 (RV770)
    1GB VRAM, 256-bit GDDR3
    PCI Express 2.0 x16

Kernel + architecture:  [uname -r -m]
2.6.32-rc8-0git091120.desktop.uvesafb x86_64

Linux distribution:  Debian unstable

Machine:  self-built
    MSI 790FX-GD70 motherboard
        socket AM3
        AMD 790FX and SB750 Chipset
    OCZ OCZ3P1600EB4GK 2x2GB DDR3 1600
    AMD Phenom II X4 955


Software versions:
    xf86-video-radeonhd:  git commit 6387ab4..., dated 11-12-2009
    Mesa-7.7-devel:  git commit 37676b3..., dated 11-15-2009
    libdrm:  release 2.4.15 tarball
    XOrg Server:  1.7.0 from Debian experimental, dated 10-04-2009
    prboom:  v2.5.0
    DOSBox:  v0.72

Additional versions:
    radeonhd:  initially was using 1.2.5 from Debian unstable; built radeon 1.3.0 from official release tarball in early November before upgrading to the version mention above on Nov. 12
    Mesa:  initially using Mesa-7.7-devel from tarball, dated 11-05-2009
    X Server:  initially using 1.6.5 from Debian unstable
    (Other software -- libdrm, prboom, and DOSBox -- remained unchanged.)

    Symptoms with OpenGL enabled did not change (on radeonhd) with any of the mentioned version changes.


Additional Information:

This problem was discovered in the process of experimenting with 2D/3D acceration support for my RV770 GPU.  Debian did not include support for Radeon 'r600' in their Mesa-7.6 packages, so I had to build upstream versions of libdrm, Mesa-7.7-devel, and xf86-video-radeonhd to get the necessary support for 'r600'.

I also have experimented with xf86-video-ati.  The "xserver-xorg-video-radeon" package in Debian unstable (from xf86-video-ati) was version 6.12.3 when I began experimenting.  It also produced the same graphics corruption I am seeing with "radeonhd", including the "r600_cp_dispatch_texture" error spam in my logs.  However, it was discovered by Alex Deucher that a problem in the "radeon" DDX driver having to do with large amounts of VRAM was the cause of the problem with that driver.  (See fdo bug #24301.)  Matthias Hopf believes that the root cause of this identical corruption (and log spam) I am experiencing with "radeonhd" is not the same as for "radeon", however.