Re: How should "max bpc" KMS property work?

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Apr 28, 2022 at 07:52:58AM +0000, Simon Ser wrote:
> On Thursday, April 28th, 2022 at 09:50, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> 
> > > > > Also like Alex said, the kernel does not know if the user prefers high
> > > > > color depth or high refresh rate either. One way to solve that is to
> > > > > light up the requested video mode any way the kernel can, and then
> > > > > report what the resulting color depth is. Another way is to have
> > > > > explicit "use this bpc or fail" KMS property, maybe in the form of 'min
> > > > > bpc' as I recall being discussed in the past, and let userspace guess
> > > > > what might work. The former is easier to light up, but probing requires
> > > > > actually setting the modes. The latter may require a lot of
> > > > > trial-and-error from userspace to find anything that works, but it
> > > > > takes only time and not blinking - as far as things can be detected
> > > > > with TEST_ONLY commits. Then one still has to ask the user if it
> > > > > actually worked.
> > > >
> > > > min_bpc sounds like something we might want for HDR use-cases, unless
> > > > the compositor has a way to confirm the output box (and format). min_bpc
> > > > would allow the KMS driver to pick the lowest required bpc so the
> > > > compositor always has a guarantee of quality.
> > >
> > > IMO that would be ideal. The driver should try to reduce bandwidth by lowering
> > > the bpc down to the min_bpc if the hardware can't drive the selected mode at a
> > > higher bpc. User space usually knows which bpc is sufficient for the use case
> > > but will never complain about too much bpc. Drivers which don't support
> > > lowering the bpc dynamically can then still go with the min_bpc and user space
> > > still gets all the modes which work with the minimum required bpc.
> >
> >
> > This would be nice, yes.
> >
> > I'm fairly sure 'min bpc' was discussed here on the dri-devel mailing
> > list in the past, but I don't remember when or by whom.
> 
> Yup. I explained there that I'd prefer "current bpc" + "user bpc" props
> and let user-space deal with the fallback logic just like it does for
> modes, modifiers, etc.

The main problem is that the bpc is not really al that well defined.
We have stuff like 4:2:0 subsampling, DSC (compression), etc. muddying
the waters. Of course max_bpc already suffers a bit from those issues,
but at least it can still claim to do what it says on the tin.
Guaranteeing any kind of minimum bpc is not possible without first
defining what that actually means.

Oh and the various processing blocks in the pipeline might also have
varying input/output precision. So those can also degrade the quality
regardless of how many bits are coming out the end of the pipe.

I suspect trying to exose all that explicitly would result in an API
that just has too many knobs and interactions between the knobs. So
likely no one would be able to succesfully use it.

-- 
Ville Syrjälä
Intel