[Intel-gfx] [RFC 3/4] drm/i915: Interrupt driven fences

[Chris Wilson]

On Fri, Mar 20, 2015 at 05:48:36PM +0000, John.C.Harrison at Intel.com wrote:
> From: John Harrison <John.C.Harrison at Intel.com>
> 
> The intended usage model for struct fence is that the signalled status should be
> set on demand rather than polled. That is, there should not be a need for a
> 'signaled' function to be called everytime the status is queried. Instead,
> 'something' should be done to enable a signal callback from the hardware which
> will update the state directly. In the case of requests, this is the seqno
> update interrupt. The idea is that this callback will only be enabled on demand
> when something actually tries to wait on the fence.
> 
> This change removes the polling test and replaces it with the callback scheme.
> To avoid race conditions where signals can be sent before anyone is waiting for
> them, it does not implement the callback on demand feature. When the GPU
> scheduler arrives, it will need to know about the completion of every single
> request anyway. So it is far simpler to not put in complex and messy anti-race
> code in the first place given that it will not be needed in the future.
> 
> Instead, each fence is added to a 'please poke me' list at the start of
> i915_add_request(). This happens before the commands to generate the seqno
> interrupt are added to the ring thus is guaranteed to be race free. The
> interrupt handler then scans through the 'poke me' list when a new seqno pops
> out and signals any matching fence/request. The fence is then removed from the
> list so the entire request stack does not need to be scanned every time.

No. Please let's not go back to the bad old days of generating an interrupt
per batch, and doing a lot more work inside the interrupt handler.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre