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?
Cheers,
Dieter
-------------------------------------------------------
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_id=3149&alloc_id=8166&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel