Quoting Chris Wilson (2019-01-24 14:40:40) > Quoting Tvrtko Ursulin (2019-01-24 14:18:54) > > > > On 23/01/2019 17:44, Chris Wilson wrote: > > > + /* > > > + * If the inflight context did not trigger the preemption, then maybe > > > + * it was the set of queued requests? Pick the highest priority in > > > + * the queue (the first active priolist) and see if it deserves to be > > > + * running instead of ELSP[0]. > > > + * > > > + * The highest priority request in the queue can not be either > > > + * ELSP[0] or ELSP[1] as, thanks again to PI, if it was the same > > > + * context, it's priority would not exceed ELSP[0] aka last_prio. > > > + */ > > > + return queue_prio(&engine->execlists) > last_prio; > > > > Could we avoid this check if we only knew the current/latest priority of > > ctx in port0? Submitted or not, depending on our policy. But is we see > > that queue_priority == port0->ctx->priority we can avoid preempting > > itself. I guess that could be defeated by a priority ctx set param after > > submission but do we care? > > It's upset because at this point we are no longer certain that > execlists->queue_priority refers to anything. We may have been trying to > schedule a preemption point on behalf of a request that has long since > completed. Or even run on an entirely different engine for veng. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
