Michel Dänzer wrote: >On Mon, 2005-05-23 at 18:45 +0200, Nicolai Haehnle wrote: > > >>It is equally likely that the lockup is caused by, say, alignment or >>wraparound issues of the ring buffer. >>Note that fglrx always submits commands in indirect buffers, which are >>stored linearly in physical memory. We, on the other hand, always submit >>commands into the ring buffer, which is not linear (because it wraps >>around). Also, fglrx likes to emit NOPs into the command stream sometimes, >>though I haven't been able to find an exact pattern in those NOPs. We never >>emit NOPs (or do we?). >> >>So the fact is: We just don't know whether alignment/wraparound can cause >>trouble. The emission of NOPs by fglrx is IMO significant evidence that >>there *are* issues in this area, at least on some chipsets, but it could >>just be some weird artifact of the fglrx codebase. >> >> > >The NOPs in the ring buffer are there for alignment/performance reasons, >they shouldn't affect lockups either way. > I do not know much about ATI processors, but could they be there to prevent unprotected pipeline stalls/conflicts which could cause lockups ? Would adding 3/4 NOPs after a command to clear the pipeline prevent the lockup ?
Cheers, Jonathan
signature.asc
Description: OpenPGP digital signature
