On 19/02/16 14:34, Chris Wilson wrote:
On Fri, Feb 19, 2016 at 02:10:44PM +0000, Tvrtko Ursulin wrote:
On 19/02/16 12:29, Chris Wilson wrote:
Exactly, we want the iomap/vmap caching thingy first :) But the
retired work queue disappears as a fallout of your previous-context idea
anyway plus the fix to avoid the struct_mutex when freeing requests.
I did not get that working yet. I think it need N previous contexts
pinned in a request, where N is equal to CSB size. Since most
pessimistic thinking is we could get that many context complete
events in a single interrupt.
The completion order is still the same as our execution order (it has to
be otherwise it violates our serialisation rules), so worst case is you
only need to keep the engine->last_context pinned along with active
references on the outstanding contexts (and those active references are
held by the following request).
Yes completion order is the same but seqno in HWS could theoretically be
ahead of the context completes by the size of CSB I thought.
Theory is that GPU could have completed N contexts, stuffed the
notifications in the CSB and then maybe the actual interrupt got
coalesced, delayed, or something. At least I thought this was what I was
observing. Not 100% sure.
But it was only a problem in the current code, where I tried to unpin
the previous contexts from the seqno based timeline of course.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
