On Tue, 2004-01-13 at 20:56, Keith Whitwell wrote: > Michel DÃnzer wrote: > > > > What makes the difference is calling _mesa_lookup_enum_by_nr() at the > > beginning of r200Enable(), probably due to the delay. Granted, it > > doesn't help with the reflections, and if those are disabled, it doesn't > > help at all, but I don't understand why delaying there would have any > > effect... > > Does a usleep(1) in the same place have the same effect?
No... unsurprisingly, it does kill performance though. (BTW, nanosleep() might be a better fallback than usleep() for throttling?) > Does the hardware actually "see" the delay? I doubt it, at least the framerate doesn't seem affected. > It will only be exposed to delays *between* command buffers - delays > aren't preserved within a buffer submitted to hardware as a whole... Hence my bafflement... what's special about _mesa_lookup_enum_by_nr()? Does the attenuation patch look good to you though? -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
