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?
Yes, quite possibly. It's hard to remember much about the problem, but the email thread around then really explained it in some detail as I recall.
Keith
------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
