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.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?
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.
Roland
------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id�66&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
