[Intel-gfx] [PATCH 2/2] drm/i915/dp: Use current cdclk for DSC Bigjoiner BW check

[Ville Syrjälä]

On Wed, Mar 29, 2023 at 04:44:12PM +0300, Lisovskiy, Stanislav wrote:
> On Wed, Mar 29, 2023 at 02:35:38PM +0300, Ville Syrjälä wrote:
> > On Wed, Mar 29, 2023 at 05:00:55PM +0530, Nautiyal, Ankit K wrote:
> > > 
> > > On 3/29/2023 4:23 PM, Ville Syrjälä wrote:
> > > > On Wed, Mar 29, 2023 at 04:06:21PM +0530, Nautiyal, Ankit K wrote:
> > > >> On 3/29/2023 3:27 PM, Ville Syrjälä wrote:
> > > >>> On Wed, Mar 29, 2023 at 02:14:49PM +0530, Ankit Nautiyal wrote:
> > > >>>> As per Bspec, Big Joiner BW check is:
> > > >>>> Output bpp <= PPC * CDCLK frequency * Big joiner interface bits /
> > > >>>> Pixel clock
> > > >>>>
> > > >>>> Currently we always use max_cdclk in the check for both modevalid
> > > >>>> and compute config steps.
> > > >>>>
> > > >>>> During modevalid use max_cdclk_freq for the check.
> > > >>>> During compute config step use current cdclk for the check.
> > > >>> Nak. cdclk is computed much later based on what is actually needed.
> > > >>> The cdclk freq you are using here is essentially a random number.
> > > >> Oh I didn't realise that, perhaps I was lucky when I tested this.
> > > >>
> > > >> So this check where CDCLK is mentioned, actually expects max_cdclk_freq?
> > > >>
> 
> We use max_cdclk_freq basically as a "hack" to estimate what could be the max
> amount of the CDCLK, because for the reasons, Ville mentioned, we can't use
> CDCLK directly here, because it hasn't been yet calculated.
> 
> However we anyway know CDCLK will be aligned accordingly to pixel rate.
> 
> > > >> If it doesnt then, we might have a compressed_bpp value, that might be
> > > >> violating the big joiner bw check.
> > > >>
> > > >> Should this be handled while computing cdclk?
> > > > Yes. I suggest adding something like intel_vdsc_min_cdclk() that
> > > > handles all of it.
> > > 
> > > 
> > > I can try that out.
> 
> It is all again about that same chicken&egg problem. 
> Our paradigm is that CDCLK is the last thing that we calculate, however that
> check instructs us to choose the output bpp which obeys
> 
> Output bpp <= PPC * CDCLK frequency * Big joiner interface bits / pixel clock
> 
> rule.
> 
> If we choose to adjust CDCLK accordingly, we loose an option to actually change
> the ourpur bpp to save the power, because theoretically we could avoid increasing
> CDCLK to match that rule, by decreasing the output bpp..
> 
> So this kinda leads us to possibly waste more power.

The main questions in selecting the bpp are what kind of
quality is achievable and/or acceptable. The rest (link
rate/cdclk/etc.) are all derived based on that. Doing it
the other way around would essentially result in 
non-deterministic behaviour.

Currently the only way to affect the quality criteria
is the max_bpc property which isn't really properly defined
when it comes to compression. Also it just specifies the
max, not the the min (or what the user would consider
acceptable).

Every now and then I muse about introducing some kind
of abstract "power vs. quality/performance" knob that would
give the driver better hints as to which the user values more.
With something like that we could try to reduce the quality
in places to achieve better power savings.

-- 
Ville Syrjälä
Intel