KMS atomic state sets, full vs. minimal (Re: [PATCH v3 0/6] Add support for atomic async page-flips)
Ville Syrjälä
ville.syrjala at linux.intel.com
Fri Sep 30 15:58:32 UTC 2022
On Fri, Sep 30, 2022 at 06:45:09PM +0300, Ville Syrjälä 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 at 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?
Also what if you want plane 1 to do an async flip, and plane 2 to do
a sync flip? With the single async flag per commit you will end up
with one of the following results:
plane 1 plane 2 outcome
can async can async async flip on both planes (totally not what you wanted)
can async can't async -EINVAL (what you actually wanted but got unfairly rejected)
can't async can async -EINVAL
can't async can't async -EINVAL
Those last two are actually reasonable outcomes since the plane
where you did want to async flip didn't support it. But the
first two are just nonsense results.
--
Ville Syrjälä
Intel
More information about the amd-gfx
mailing list