Re: KMS atomic state sets, full vs. minimal (Re: [PATCH v3 0/6] Add support for atomic async page-flips)

[Pekka Paalanen <ppaalanen@gmail.com>]

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

On Fri, 30 Sep 2022 18:45:09 +0300
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> On Fri, Sep 30, 2022 at 06:37:00PM +0300, Pekka Paalanen wrote:
> > On Fri, 30 Sep 2022 18:09:55 +0300
> > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> >   
> > > That would actively discourage people from even attempting the
> > > "just dump all the state into the ioctl" approach with async flips
> > > since even the props whose value isn't even changing would be rejected.  
> > 
> > About that.
> > 
> > To me it looks like just a classic case of broken communication.
> > 
> > The kernel developers assume that of course userspace will minimize the
> > state set to only those properties that change, because...?
> > 
> > Userspace developers think that of course the kernel will optimize the
> > state set into minimal changes, because the kernel actually has the
> > authoritative knowledge of what the current state is, and the driver
> > actually knows which properties are costly and need to be optimized and
> > which ones don't matter. It has never even occurred to me that the
> > kernel would not compare next state to current state.
> > 
> > No-one ever documented any expectations, did they?  
> 
> Do you really want that for async flips? Async flips can't be
> done atomically with anything else, so why are you even asking
> the kernel to do that?

I'm not talking about async flips only.

I'm talking about atomic commits in general. I don't think it's a good
idea to make async atomic commits behave fundamentally different from
sync atomic commits wrt. what non-changing state you are allowed to
list in your state set or not.

Isn't there common DRM code to convert an atomic commit state set into
state objects? It probably starts by copying the current state, and
then playing through the commit state set, setting all listed
properties to their new values? Why wouldn't that loop maintain the
knowledge of what actually changed?

When you copy the current data, reset all changed-flags to false. When
you apply each property from the commit set, compare the value and set
the changed-flag only if the value changes.

This manufacturing of the new tentative state set happens at atomic
commit ioctl time before the ioctl returns, right? So the current state
is well-defined: any previous atomic sync or async commit can be assumed to
have succeeded even if it hasn't applied in hardware yet if the commit
ioctl for it succeeded, right?


Thanks,
pq

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