Re: [PATCH] drm: add capability DRM_CAP_ASYNC_UPDATE

[Michel DÃnzer]

On 2018-12-21 2:26 p.m., Daniel Vetter wrote:
> On Fri, Dec 21, 2018 at 10:47:27AM +0100, Michel DÃnzer wrote:
>> On 2018-12-20 6:16 p.m., Michel DÃnzer wrote:
>>> On 2018-12-20 6:09 p.m., Daniel Vetter wrote:
>>>> On Thu, Dec 20, 2018 at 6:03 PM Alex Deucher <alexdeucher@xxxxxxxxx> wrote:
>>>>> On Thu, Dec 20, 2018 at 11:54 AM Daniel Vetter <daniel@xxxxxxxx> wrote:
>>>>
>>>>>> Not sure about the gamma thing since we had opposite bugs on i915
>>>>>> about gamma not being vsynced and tearing terribly. Cursor is special
>>>>>> since it tends to be too small to notice tearing.
>>>>>
>>>>> Our cursor hw (and possibly gamma as well Nicholas?  Harry?) is double
>>>>> buffered, so we can update it any time for the most part and the
>>>>> changes won't take affect until the next vupdate period.
>>>>
>>>> Hm, I guess we could make the gamma update optionally async, and let
>>>> drivers deal. The issue is that the current async helper stuff won't
>>>> cope with gamma updates (it's aimed at plane updates only, not at crtc
>>>> property updates). Or we get userspace to do proper atomic updates. Or
>>>> we do some faking in the kernel, e.g. waiting with the gamma update
>>>> until the next atomic update happens. But that kinda breaks
>>>> ->atomic_check.
>>>
>>> Would it be possible to merge gamma changes into a pending commit, if
>>> there is one, and create a new commit otherwise?
>>>
>>> Otherwise the atomic API just moves this same problem to be solved by
>>> userspace.
>>
>> Actually, I'm not sure this is even solvable in a Xorg driver. When it
>> gets called to update the gamma LUT:
>>
>> 1. If there's a pending atomic commit, it cannot amend that, can it?
> 
> Yup, but on the kernel side we kinda have the same problem.

It's probably easier to solve in the kernel though; any solution
allowing userspace to amend commits would likely need similar changes in
the kernel anyway.


>> 2. It has no way of knowing when the next atomic commit would be
>> submitted e.g. for a page flip, so it kind of has to create its own
>> commit for the gamma update.
> 
> Block handler is what I had in mind for the fallback commit, if no other
> commit happened meanwhile (which would need to include it).

The BlockHandler runs more or less immediately after the gamma update,
after any other X11 requests submitted later by the same client and
flushed to the X server together. So this would still result in a commit
with only the gamma update most of the time. There might be a small
chance of combining with a flip with something like Night Light which is
done by the compositor itself (but still only if the compositor defers
the gamma update until just before it call SwapBuffers), basically 0
chance with something separate like RedShift.


-- 
Earthling Michel DÃnzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer