MASTER: direct rendering missing on ATI Radeon XPRESS 200M

[revmouse]

In Dapper Flight 5, glxgears reports 'direct rendering: no' when in xorg after a fresh installation.

Xorg.0.log reports:
(II) RADEON(0): [drm] drmOpen failed
(EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI.

[Pheldens (pheldens)]

Created an attachment (id=4827)
Xorg.0.log r300-20060304-linux.i386

It hasn't worked with earlier versions either, nor do I know if it should work
at all.

[Sroland-vmware (sroland-vmware)]

It "should not work" currently. The pci id is not present in drm, since if you
add it it will just lock up at xorg startup. Current xorg radeon driver cannot
configure the memory side of things of the xpress200m chips correctly.

[revmouse (revmouse)]

In Dapper Flight 5, glxgears reports 'direct rendering: no' when in xorg after a fresh installation.

After installing ATI's latest fglrx driver, everything works fine.

Xorg.0.log reports:
(II) RADEON(0): [drm] drmOpen failed
(EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI.

Attached are my lspci -v, dmesg, and Xorg.0.log.

--------------------------begin lspci -v---------------------------------
0000:00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge
 Subsystem: Hewlett-Packard Company: Unknown device 3085
 Flags: bus master, 66MHz, medium devsel, latency 64

0000:00:01.0 PCI bridge: ATI Technologies Inc: Unknown device 5a3f (prog-if 00 [Normal decode])
 Flags: bus master, 66MHz, medium devsel, latency 64
 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
 I/O behind bridge: 00009000-00009fff
 Memory behind bridge: b0100000-b01fffff
 Prefetchable memory behind bridge: 00000000c0000000-00000000cff00000
 Capabilities: [44] #08 [a803]
 Capabilities: [b0] #0d [0000]

0000:00:04.0 PCI bridge: ATI Technologies Inc: Unknown device 5a36 (prog-if 00 [Normal decode])
 Flags: bus master, fast devsel, latency 0
 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
 Capabilities: [50] Power Management version 3
 Capabilities: [58] #10 [0041]
 Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
 Capabilities: [b0] #0d [0000]
 Capabilities: [b8] #08 [a803]

0000:00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (prog-if 10 [OHCI])
 Subsystem: ATI Technologies Inc IXP SB400 USB Host Controller
 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 225
 Memory at b0000000 (32-bit, non-prefetchable) [size=4K]
 Capabilities: [d0] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-

0000:00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (prog-if 10 [OHCI])
 Subsystem: ATI Technologies Inc IXP SB400 USB Host Controller
 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 225
 Memory at b0001000 (32-bit, non-prefetchable) [size=4K]
 Capabilities: [d0] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-

0000:00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller (prog-if 20 [EHCI])
 Subsystem: ATI Technologies Inc IXP SB400 USB2 Host Controller
 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 225
 Memory at b0002000 (32-bit, non-prefetchable) [size=4K]
 Capabilities: [dc] Power Management version 2
 Capabilities: [d0] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-

0000:00:14.0 SMBus: ATI Technologies Inc IXP SB400 SMBus Controller (rev 10)
 Subsystem: Hewlett-Packard Company: Unknown device 3085
 Flags: 66MHz, medium devsel
 I/O ports at 8400 [size=16]
 Memory at b0003000 (32-bit, non-prefetchable) [size=1K]
 Capabilities: [b0] #08 [a802]

0000:00:14.1 IDE interface: ATI Technologies Inc Standard Dual Channel PCI IDE Controller ATI (prog-if 8a [Master SecP PriP])
 Subsystem: Hewlett-Packard Company: Unknown device 3085
 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 217
 I/O ports at <ignored>
 I/O ports at <ignored>
 I/O ports at <ignored>
 I/O ports at <ignored>
 I/O ports at 8410 [size=...

[Txukie (albertodetena)]

Same here, using radeon driver doesnt give me direct rendering, which I used to get in flight 3, installed fglrx and everything is OK but I cant use hibernate anymore (damn ATI), please somebody fix the open source drivers!

[Matt Zimmerman (mdz)]

Please attach these files; such long comments are very hard to read, especially when mixing different output together

[Ross Vandegrift (vandegrift)]

Shared memory Radeons use an incompatible gart interface and do not yet support direct rendering with X.Org's drivers.

Search bugs.freedesktop.org for any number of references.

[revmouse (revmouse)]

It doesn't work with dedicated memory either.

On 4/21/06, Ross Vandegrift <email address hidden> wrote:
>
> Shared memory Radeons use an incompatible gart interface and do not yet
> support direct rendering with X.Org's drivers.
>
> Search bugs.freedesktop.org for any number of references.
>
> --
> direct rendering missing on ATI Radeon XPRESS 200M
> https://launchpad.net/bugs/36314
>

[wasman (thomas-plassan)]

My laptop is an HP Pavilion zv6013 EA with ATI Radeon XPRESS 200M .
It doesn't work with mine either !!!
I've tried to install drivers through a cd-r but it tells me that I haven't the right to do it though I'm connected as "root".
How to install fglrx or something else ???
Ubuntu is the only distro I want to install, I've tried many others but I don't like them.
This bug report is the only one where I've found the problem :
[4294672.504000] PCI: Cannot allocate resource region 7 of bridge 0000:00:04.0
[4294672.504000] PCI: Cannot allocate resource region 8 of bridge 0000:00:04.0
but I have this line too :
[4294672.504000] PCI: Cannot allocate resource region 9 of bridge 0000:00:04.0

I hope the problem with this card will be fixed soon...

[wasman (thomas-plassan)]

Thank you very much Timothy McCown.You answered very quickly !
I'll try to use the URL's method...

[Morfic-sourcemage (morfic-sourcemage)]

what is the current status of this?
has any work been done for xpress 200m?

i have a 5955 ID which also does not work accelerated with xorg-server 1.1.0,
mesa 6.5 and xf86-video-ati 6.6.0, kernel modules from 2.6.18-rc1 on an amd64

if there is something i can help testing i would be more than glad to do so
seeing how the code on RS480 merely says "This probably won't work" i was
wondering if there is any guessing that hasn't been done that i could do to find
something that helps on this.
In that case a good starting area would be welcome.
Any code that needs testers, send it my way.

Thanks in advance for your attention.

[agd5f (agd5f)]

Until someone figures out what's needed (memory controller and otherwise), these
chips will remain unsupported from the DRI perspective. There has been no new
progress on these chips as far as I know. If fglrx supports the DRI on these
chips, you could look at register and command packet dumps to see how it is set
up, then code up something similar in the open driver.

[Pascal d'Hermilly (pascal-tipisoft)]

I confirm,
This is also a problem in Edgy.

[Timo Jyrinki (timo-jyrinki)]

It does not work because AMD / ATI have not given out the information with which the integrated ATI graphics could be supported in 3D. So this is more like a wishlist item in importance.

[Peter Whittaker (pwwnow)]

If this is a wishlist item (see previous comment), should we mark this report as rejected?

Or should we leave it open for testing under Feisty, since proprietary drivers will be available?

[revmouse (revmouse)]

Will the proprietary drivers be available by default after install? I opened
the bug report initially because the card didn't work out of the box.

On 2/13/07, Peter Whittaker <email address hidden> wrote:
>
> If this is a wishlist item (see previous comment), should we mark this
> report as rejected?
>
> Or should we leave it open for testing under Feisty, since proprietary
> drivers will be available?
>
> --
> direct rendering missing on ATI Radeon XPRESS 200M
> https://launchpad.net/bugs/36314
>

[Marcelo Boveto Shima (marceloshima)]

I have this card and I want to make this work, but I have some questions.
It's a drm, dri or xorg driver bug?
What have to be done? What files should be changed? It is too difficult?

[Timo Jyrinki (timo-jyrinki)]

The "wishlist" can be marked in the Importance column by the package owners, so no need to close this. Furthermore, this should stay open as long as the support is not in the open source driver (xserver-xorg-video-ati), whether or not there are closed drivers installed by default.

The proprietary drivers won't be used by default in feisty, as it was decided recently. The decision might change for feisty+1, but probably only so that it affects the newest Radeons (X1300 - X1950 or newer). Those don't have even 2D support out-of-the-box because ATI/AMD has not allowed the already-written 2D driver to be published (written under NDA).

Meanwhile, anyone purchasing new hardware should consider Intel's offerings and Intel's integrated graphics (GMA 950, GMA X3000), to which open source drivers are developed together with the vendor and the community. It could also be hoped that ATI would change its policies now that it was acquired by AMD.

[Timo Aaltonen (tjaalton)]

Timothy: please test Feisty beta when it is available next week to see if DRI works.

[Brian Ealdwine (eode)]

..not working in feisty. For now, use ati's fglrx drivers if you want dri. Until ATI posts enough info to make useful open-source drivers, or until the hardware has been figured out in some other way, we'll need to use the proprietary ones. If you want to use beryl/compiz, check out xgl. Not as nice as AIGLX, but still decent. If you're buying new hardware, buy nvidia or intel.

[Timo Aaltonen (tjaalton)]

Indeed, DRI does not work for the shared memory Radeons with free driver.

[Marco Trevisan (Treviño) (3v1n0)]

Something is happening, isn't it?!
http://gitweb.freedesktop.org/?p=mesa/drm.git;a=commitdiff;h=a70f8e0ab265cc4a26ed2f9e92ab0618bd920a93;hp=b25558bb7377f6df6d457b50067a1d245f7911fd

[Airlied-freedesktop (airlied-freedesktop)]

I've done DRM and DDX fixes.. however the 3D driver in Mesa now needs fixes...

[Marco Trevisan (Treviño) (3v1n0)]

Something is happening...
Here's a patch that adds drm support fo Xpress200m: http://gitweb.freedesktop.org/?p=mesa/drm.git;a=commitdiff;h=a70f8e0ab265cc4a26ed2f9e92ab0618bd920a93;hp=b25558bb7377f6df6d457b50067a1d245f7911fd

[Phillipezolt (phillipezolt)]

I have the latest and greatest xorg+drm+Mesa. I've done a little experimenting.

0) If you want to play, get the lastest xorg, drm, Mesa and...

You'll have to comment out the "return NULL" in radeon_screen.c, to play with things...)
      fprintf(stderr, "Warning, xpress200 detected. Won't work.\n");
      // return NULL;

1) I've been playing with the Mesa samples (rather than gears).

A few of them have a static screen. However, everytime you cause them to repaint, it causes the colors to flash wildly. (Try the 'prim' test, and just move it around the screen.. You'll see what I mean.)

However, the text does show up. So, SOMETHING is working.

NOTE: I haven't had much time to screw with this, but I am going to try some very basic things (draw a single trinagle, glReadPixels, etc ) and see if the components work. It looks like "progs/trivial" in Mesa has some good places to start.

2) If you run the "logo" sample, and push the 'l' key, the proper SGI logo will be displayed!

However, I think that this is because the driver shifts to software mode for drawing. But atleast SOME geometry is making it properly to the screen.

3) tcl_mode
...
(I haven't yet tested with the following in "/etc/drirc", but I will tonight..)
<driconf>
        <device screen="0" driver="radeon>
          <application name="Default">
           <option name="tcl_mode" value="0"/>
          </application>
        </device>
</driconf>

[Awj-in-japan (awj-in-japan)]

> 3) tcl_mode
> ...
> (I haven't yet tested with the following in "/etc/drirc", but I will tonight..)
> <driconf>
> <device screen="0" driver="radeon>
> <application name="Default">
> <option name="tcl_mode" value="0"/>
> </application>
> </device>
> </driconf>

The second line isn't quite right, it should be:

<device screen="0" driver="r300">

[Sroland-vmware (sroland-vmware)]

(In reply to comment #10)
> > 3) tcl_mode
> > <option name="tcl_mode" value="0"/>
> The second line isn't quite right, it should be:
>
> <device screen="0" driver="r300">
Doesn't really matter the init code defaulted to disable tcl mode for ages. That the driver then later ignored it is an entirely different matter (which Dave Airlie has now fixed), no amount of driconf tweaking would have helped you with that...

[Phillipezolt (phillipezolt)]

Alright, more digging. I've tried to whittle things down to the simpliest possible test case.

If I write a small gl program that simply clears the front buffer to black (0.0,0.0,0.0,0.0), it doesn't work properly. (clear.c in mesa/progs/trivial would probably work as well.)

I've hacked things, so that everytime I press 'a', it will call glClear(GL_COLOR_BUFFER_BIT).

Everytime I press 'a' the window is cleared to a different color. It seems to cycle through read, yellow, green. (blue doesn't seem to be present.)

However, if I disable color-tiling, it doesn't the same thing, but with shades of purple, blue and red. I probably need to dump the glClear command stream of the fglrx driver on the same program and compare it to r300ClearBuffer.

I just need to find the tool to do that. (kmmio?)

[Airlied-freedesktop (airlied-freedesktop)]

I've already gotten a track from the trivial clear program using glxtest...

http://www.skynet.ie/~airlied/dri/mypa.parsed

I'm trying to reproduce this in mesa, we emit a lot of register that don't exist on the rs480 due to the lack of vertex shading hw... first up I'm trying to remove those emits...

[Airlied-freedesktop (airlied-freedesktop)]

okay I've gotten trivial/clear to at least showing its blue color....

now for triangles hopefully...

[Nigel-nigel (nigel-nigel)]

Just built and tried current git. I have some success. glxgears doesn't do the cube, but doesn't crash either. My card is a non-vanilla 5955 in a Mitac 8350 laptop. I'm more than happy to test any updates.

[Airlied-freedesktop (airlied-freedesktop)]

glxgears should work.. what do you get?

I've gears and googleearth working on my rs480 fine with git versions of xf86-video-ati, drm and mesa.

[Akirchhoff135014 (akirchhoff135014)]

I just updated to current git for xf86-video-ati, drm, and mesa in the last 30 minutes. This is what glxgears gives on my Xpress 200M (0x5975):

http://www.visualtech.com/Xpress-200M-glxgears.png

[Airlied-freedesktop (airlied-freedesktop)]

try again.. I fixed a bug that was introduced lately.

[Nigel-nigel (nigel-nigel)]

No success, sorry. To be sure, I updated and rebuilt everything. Any logs or such like I could send that might help?

[Akirchhoff135014 (akirchhoff135014)]

Well, it does work here after that fix. glxgears, googleearth, and various mesa demos. Great work guys!

[Nigel-nigel (nigel-nigel)]

In that case, I'll try again.

Compiz too?

[Akirchhoff135014 (akirchhoff135014)]

No, compiz and beryl both crash the X server. Most of the GL screensavers seem to work, as does supertux. Googleearth, as I previously said, does work. Supertux works well. Neverball/neverputt and tuxkart definitely have issues :-)

[Nigel-nigel (nigel-nigel)]

No success here, I'm afraid. What can I do to help diagnose the cause?

Regards,

Nigel

[Airlied-freedesktop (airlied-freedesktop)]

you are still seeing the broken gears? the same way?

I can't see how that is happening if you are running the latest Mesa.

[Nigel-nigel (nigel-nigel)]

Yes and yes. I double checked libGL.so and it looks ok. I'll try again. Given what you say, it's almost certainly -EPEBKAC :)

[Nigel-nigel (nigel-nigel)]

Hmm. Doesn't look like it is -EPEBKAC. I've carefully checked that I have up-to-date git, have rebuilt and reinstalled and checked /usr/lib and ldconfig -p. I'm still getting the display that was shown above. The sterr/stdout output is as follows:

nigel@nigel:~/Programming/xorg/mesa/drm$ GLX_DEBUG=1 glxgears
Warning, xpress200 detected.
libGL warning: 3D driver claims to not support visual 0x4c

Something else I could try?

Regards,

Nigel

[Airlied-freedesktop (airlied-freedesktop)]

nope I'm lost as to why gears is broken for you.

can you tell me the id of the top commit in your mesa git tree?

[Nigel-nigel (nigel-nigel)]

Commit: 90630feeec52c6d4f2a17f75cdf3dab9f5baf923
Author: Dave Airlie <email address hidden> Sat, 02 Jun 2007 16:21:50 +1000

    r300: fix non-tcl rs4xx again.

[Airlied-freedesktop (airlied-freedesktop)]

nope that is the latest commit that matters. so I'm very lost as to why my rs480 works and adamk's works but yours doesn't and still exhibits the behaviour of the screenshot...

[Nigel-nigel (nigel-nigel)]

I just did another cg pull and a couple of new commits have just gone in. They
shouldn't matter, should they?

[Nigel-nigel (nigel-nigel)]

Would there be some lowlevel debugging I could enable that might help find the cause?

[Airlied-freedesktop (airlied-freedesktop)]

not that I can help with from here, can you try if commit 8130a4fe982a7583e439a1fac61c5050f85bdf46

is broken as well for you?

[Nigel-nigel (nigel-nigel)]

Ok. Trying cg seek 8130a4fe982a7583e439a1fac61c5050f85bdf46, rebuild and reinstall...

[Nigel-nigel (nigel-nigel)]

By the way, I don't know if 200M's were made for 32 bit machines, but I'll mention that this is a 64 bit lappy and distro.

[Michel-tungstengraphics (michel-tungstengraphics)]

(In reply to comment #31)
> Would there be some lowlevel debugging I could enable that might help find the
> cause?

Try

LIBGL_DEBUG=verbose glxgears

and verify it's picking up the correct r300_dri.so.

[Nigel-nigel (nigel-nigel)]

Yaaaaaaaaaaay!

That put me on the right track. The modules are still being installed in /usr/X11R6/lib/modules/dri unless the user hacks the config. I did rm -rf /lib/modules/dri; ln -s /usr/X11R6/lib/modules/dri . and now I'm in business. Thanks, Dave and thanks Michel for your help.

[antok.tm (antok-elect-eng)]

Does anyone tried the above patch ?

[Pavel Rojtberg (rojtberg)]

I tried the git head which includes that patch an that are my results:
http://www.madman2k.net/article/89#part1

[Nigel-nigel (nigel-nigel)]

Status update:

Most DRI now working. Compiz starts but textures are scaled incorrectly. Opacity seems to play a role - if I make a window semitransparent, the scale is correct. Great work, Dave!

[Airlied-freedesktop (airlied-freedesktop)]

this bug is fixed compiz isn't yet but this bug I think should be closed.

[Nigel-nigel (nigel-nigel)]

So you think the texture size issue is a compiz problem?

[Timo Aaltonen (tjaalton)]

Gutsy has all the bits for XPRESS 200M dri-support. If you have issues with it, please open new bugs. Thanks!

[Airlied-freedesktop (airlied-freedesktop)]

in case anyone cares I fixed the compiz problem now in mesa master..