Created attachment 4827 [details]
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.

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.

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.

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.

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.

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?

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

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

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>

> 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">

(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...

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?)  

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...

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

now for triangles hopefully...

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.

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.

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

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

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

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

In that case, I'll try again.

Compiz too?

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 :-)

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

Regards,

Nigel

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.

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 :)

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

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?

Commit: 90630feeec52c6d4f2a17f75cdf3dab9f5baf923 
Author: Dave Airlie <airlied@linux.ie> Sat, 02 Jun 2007 16:21:50 +1000 

    r300: fix non-tcl rs4xx again.

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...

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

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

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

is broken as well for you?

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

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.

(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.

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.

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!

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

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

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