Quoting Chris Wilson (2019-04-01 15:18:38) > Ideally we only need one semaphore per ring to accommodate waiting on > multiple engines in parallel. However, since we do not know which fences > we will finally be waiting on, we emit a semaphore for every fence. It > turns out to be quite easy to trick ourselves into exhausting our > ringbuffer causing an error, just by feeding in a batch that depends on > several thousand contexts. > > Since we never can be waiting on more than one semaphore in parallel > (other than perhaps the desire to busywait on multiple engines), just > pick the first fence for our semaphore. If we pick the wrong fence to > busywait on, we just miss an opportunity to reduce latency. > > An adaption might be to use sched.flags as either a semaphore counter, > or to track the first busywait on each engine, converting it back to a > single use bit prior to closing the request. Grrr, this disables semaphores for basic-sequential gem_exec_nop. Maybe allow semaphores for the same GEM context regardless. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
