Am Montag, 31. Mai 2004 02:16 schrieb Roland Scheidegger: > Dieter N�tzel wrote: > > Am Freitag, 28. Mai 2004 19:22 schrieb Roland Scheidegger: > >>So, when I updated radeon_maos_arrays.c and compiled that (btw really > >>brave souls can try it out, just define RADEON_OLD_PACKETS to 0 in > >>radeon_context.h and RADEON_MAOS_VERTS to 0 in radeon_maos.c, that > >>codepath was only enabled in april 2002 for 9 days and probably caused a > >>15% slowdown according to that mail, > >>http://marc.theaimsgroup.com/?l=dri-devel&m=101836484905209&w=2, so the > >>question of course is would implementing the maos_verts path for r200 > >>driver result in a 15% speedup?), I came across some stuff which seems > >>like it could be related to the r200 lockups. > >>The radeon driver today still uses RADEON_OLD_PACKETS 1, the r200 driver > >>also had the same variable (R200_OLD_PACKETS) but set to 0 (and not > >>implemented the other path, some hours ago I've removed the unused > >>macro). However, the reason old packets are used for radeon is according > >>to the cvs entry (3 jul 2002) this: "Use old packets (aos+vertex data in > >>one packet) to avoid problems when buffer wraps between the two new > >>packets. Reported by Michael a while ago...". This refers to this mail, > >>http://marc.theaimsgroup.com/?l=dri-devel&m=102395055325248&w=2. > >> > >>But if I look at that code, the r200 driver seems to implement it in > >>exactly the same way as the radeon driver (if RADEON_OLD_PACKETS is not > >>set). So could this be the reason why a simple glxgears + quakeIII still > >>locks up the chip? > > > > Do you have something for testing? > > No. However, I've done some tests on the radeon (btw I really should > have tried the recover-from-lockup patches, had to reboot 20 times (one > time though I got a complete kernel lockup (no more sysrequest) instead > of just a gpu lockup for some reason) and collected some results. Much > to my surprise, the radeon_maos_arrays path which wasn't used for years > and I've brought up to date almost works, it locks up quakeIII almost > instantly after starting the demo playback, but simple Mesa demos run > well. Not sure if I've introduced some errors when updating it or it was > broken a bit before. > But testing simple demos, there's a clear pattern: > RADEON_OLD_PACKETS and RADEON_MAOS_VERTS set, two demos (gloss + ipers, > I've also tested different combinations like quakeIII and glxgears, but > couldn't use that for the arrays path since it locked up even when > running alone) running simultaneously works without lockups (though > ipers gets very slow). > RADEON_OLD_PACKETS set and RADEON_MAOS_VERTS not set is not possible, so > next test is RADEON_OLD_PACKETS not set and RADEON_MAOS_VERTS set. > QuakeIII running alone works fine, but ipers and gloss (or quake3 + > glxgears) locks up very fast. > Last, both RADEON_OLD_PACKETS and RADEON_MAOS_VERTS not set, two demos > running concurrently also lock up pretty quickly. > So: > a) Interestingly, it didn't make much if any performance difference > which path was used (ipers, glxgears, fire) at maximum 3% slower with > arrays (remember, no Q3 numbers unfortunately...) > b) the reason why the radeon driver defaults to OLD_PACKETS since two > years is indeed still valid > c) the r200 driver seems to use exactly the same code to emit vertex > packets as the broken radeon driver path does > > So, I think this is indeed the reason of these lockups.
Any progress? Maybe related to 'Hard lockup with r200 DRI driver' or 'r200 driver crashes'? -Dieter ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
