[Intel-gfx] [PATCH 4/5] drm/i915: Downgrade NEWCLIENT to non-preemptive

[Tvrtko Ursulin]

On 17/05/2019 14:30, Chris Wilson wrote:
> 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.

Sorry for some reason I was thinking of a single timeline contexts when 
thinking about the commit message. :(  Numbers prove we need it..

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>

Regards,

Tvrtko