On Tue, 17 Feb 2004 17:46:48 +0100 Roland Scheidegger <[EMAIL PROTECTED]> wrote:
[snip]
The GLX visual matching code is pretty much driver-independant, so it's odd this would only be a problem with the mga driver. That said, there were some changes in that area since XFree86 4.3, but I
don't think the visual matching code was broken in a way which could have caused this bug - it would be helpful if the OP could test this with a newer XFree86 version. Unfortunately though I believe the dri snapshots (both driver and the (needed) XFree server from the extras directory) do not include the changed glx stuff.
The snapshots include libGL. Any GLX changes should be in there. It's
possible though, that the wrong libGL is used on the target system, not the one installed by the snapshot. Only ldd can tell. ;-)
But only the client-side glx changes are included in libGL. There was at least one bug which required server-side fixing (the wrongly reported buf size). Though I think you're right that all changes which could be relevant to this bug are indeed client-side.
But in this case I think it should still work, just dead slow (with a software fallback). If I understand the torcs thread correctly, it just crashed instead.
[snip]
If you want to test it start TORCS with -s to disable multitexturing.
That's also something which shouldn't be necessary, the G400/G450/G550 should work AFAIK just fine with multitexturing.
The microcode in the MGA driver can't handle multi texturing with projective textures. See Ville's comments in the thread "Slow Mtex in
DRI".
Roland
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
