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?
Couple of questions -
What's going on here - is there something the hw can't handle?
+ if ( fcmd[LIT_ATTEN_CONST] == 1.0 ) {
+ /* Can't do even constant attenuation, disable */
+ icmd[idx] &= ~( R200_LIGHT_0_ENABLE_RANGE_ATTEN << shift);Secondly - what's the ATTEN_XXX constant? I realize that it's mine, but I can't remember what it's all about...
Keith
------------------------------------------------------- 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
