Nicolai Haehnle wrote:
According to lspci, it's an "ATI Technologies Inc RV350 [Mobility Radeon
9600 M10]"
That chip is actually known to work fine. Have you tried to run ordinary
OpenGL applications within the normal X.Org server (e.g. Glean, TuxRacer,
Cube, ...)? Are you seeing lockups there, too?
Yes, in fact, mostly it does work fine, and has done so for a while now:
- glxgears works, though it only gives me 500 fps (on a Pentium M 1400
- I should get at least 1000 or 1500, right?)
- The xscreensaver GL hacks work fine, apart from some display problems
on some of them (e.g. mirrorblob) and slowness in uploading textures
- Quake3 is a little bit slow but works fine.
If the lockups happen only with Xglx, this could well be an Xglx-specific
software issue. In this case, you should try enabling the DRM debugging
options (modprobe drm debug=1) and have a look into the
dmesg/syslog/wherever kernel messages end up on your system to see what
happens around the the time of lockup. Also, you should obviously make sure
that all your components are recent (X.Org CVS, r300 CVS, Mesa CVS).
Ok. I'll see if I can get the messages then. I don't think the machine
locks up completely.
If it's a bug on our (i.e. the driver's) side, we should fix it, whether or
not Xglx itself is in a usable state. It's likely that Xglx hits code paths
that aren't used by most programs.
That's what I thought as well.
Cheers,
Lorenzo
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
