Re: [PATCH v3] Documentation: gpu: Mention the requirements for new properties

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2521 bytes --]

On Tue, 15 Jun 2021 12:45:57 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:

> On Tue, Jun 15, 2021 at 07:15:18AM +0000, Simon Ser wrote:
> > On Tuesday, June 15th, 2021 at 09:03, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >   
> > > indeed it will, but what else could one do to test userspace KMS
> > > clients in generic CI where all you can have is virtual hardware? Maybe
> > > in the long run VKMS needs to loop back to a userspace daemon that
> > > implements all the complex processing and returns the writeback result
> > > via VKMS again? That daemon would then need a single upstream, like the
> > > kernel, where it is maintained and correctness verified.  
> > 
> > The complex processing must be implemented even without write-back, because
> > user-space can ask for CRCs of the CRTC.
> >   
> > > Or an LD_PRELOAD that hijacks all KMS ioctls and implements virtual
> > > stuff in userspace? Didn't someone already have something like that?
> > > It would need to be lifted to be a required part of kernel UAPI
> > > submissions, I suppose like IGT is nowadays.  
> > 
> > FWIW, I have a mock libdrm [1] for libliftoff. This is nowhere near a full
> > software implementation with write-back connectors, but allows to expose
> > virtual planes and check atomic commits in CI.
> > 
> > [1]: https://github.com/emersion/libliftoff/blob/master/test/libdrm_mock.c
> >   
> > > For compositor developers like me knowing the exact formulas would be a huge
> > > benefit as it would allow me to use KMS to off-load precision-sensitive
> > > operations (e.g.  professional color management). Otherwise, compositors
> > > probably need a switch: "high quality color management? Then do not use KMS
> > > features."  
> > 
> > I think for alpha blending there are already rounding issues depending on the
> > hardware. I wouldn't keep my hopes up for any guarantee that all hw uses the
> > exact same formulae for color management stuff.  
> 
> Good, because otherwise you would be very quickly disappointed :-)
> 
> For scaling we would also need to replicate the exact same filter taps,
> which are often not documented.

That is where the documented tolerances come into play.

Userspace projects need screenshot-based testing, and we need to know
how much tolerance we should allow or expect.

Good reminder about CRCs. CRCs have zero tolerance, so they are not
useful for testing properties that have any leeway, are they?


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]