Quoting Tvrtko Ursulin (2019-05-17 13:55:48)
>
> On 15/05/2019 14:00, Chris Wilson wrote:
> > Commit 1413b2bc0717 ("drm/i915: Trim NEWCLIENT boosting") had the
> > intended consequence of not allowing a sequence of work that merely
> > crossed into a new engine the privilege to be promoted to NEWCLIENT
>
> What do you mean with crossed into a new engine? At first I thought the
> statement implies the engine timeline was used to query for previous
> request, but that's not true.
Our previous test was if all previous requests in the ring (along the
engine timeline) were complete then give this new request a boost. That
also gave the boost to any dependencies in other contexts and across
engines -- the consideration there was for a display server who was only
blitting from client buffers into the framebuffer to get an early boost
and bump all of its clients in order to be ahead of the next vblank. The
second thought was that was a bit too wide, but now we have evidence
from will-it-scale style oversaturation of transcode work that we should
take into account the workloads across engines and across contexts.
I think these two patches are quite nice in that effect, work is
essentially bottled up until required and so should arrive at the GPU in
batches of related work (but we don't prevent work from being executed
if the GPU is idle). Then combined with the timeslice we will
round-robin between the work required for the external observer to make
progress before doing other work.
It makes a pretty picture in my head and so far looks respectable in the
wsim comparisons (as well as the sample transcode reproducers). The
casualty is the realtime-response under load has lost its preemptive
power, and is relegated to just towards the head of the queue as opposed
to the front. On the other head, it makes WAIT far, far less special.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
