Re: [RFC 4/4] drm/i915: Expose RPCS (SSEU) configuration to userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 02, 2017 at 10:33:19AM +0000, Oscar Mateo wrote:
> 
> 
> On 05/02/2017 11:49 AM, Chris Wilson wrote:
> >We want to allow userspace to reconfigure the subslice configuration for
> >its own use case. To do so, we expose a context parameter to allow
> >adjustment of the RPCS register stored within the context image (and
> >currently not accessible via LRI).
> 
> Userspace could also do this by themselves via LRI if we simply
> whitelist GEN8_R_PWR_CLK_STATE.
> 
> Hardware people suggested this programming model:
> 
> - PIPECONTROL - Stalling flish, flush all caches (color, depth, DC$)
> - LOAD_REGISTER_IMMEDIATE - R_PWR_CLK_STATE
> - Reprogram complete state

Hmm, treating it as a complete state wipe is a nuisance, but fairly
trivial. The simplest way will be for the user to execute the LRI batch
as part of creating the context. But there will be some use cases where
dynamic reconfiguration within an active context will be desired, I'm
sure.

> >If the context is adjusted before
> >first use, the adjustment is for "free"; otherwise if the context is
> >active we flush the context off the GPU (stalling all users) and forcing
> >the GPU to save the context to memory where we can modify it and so
> >ensure that the register is reloaded on next execution.
> 
> There is another cost associated with the adjustment: slice poweron
> and shutdown do take some time to happen (in the order of tens of
> usecs). I have been playing with an i-g-t benchmark to measure this
> delay, I'll send it to the mailing list.

Hmm, I thought the argument for why selecting smaller subslices gave
better performance was that it was restoring the whole set between
contexts, even when the configuration between contexts was the same.

As always numbers demonstrating the advantage, perhaps explaining why
it helps, and also for spotting when we break it are most welcome :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux