[PATCH 3/6] amd/display: fail on cursor plane without an underlying plane

[Michel Dänzer]

On 2021-03-08 9:38 p.m., Kazlauskas, Nicholas wrote:
> On 2021-03-08 3:18 p.m., Daniel Vetter wrote:
>> On Fri, Mar 5, 2021 at 10:24 AM Michel Dänzer <michel at daenzer.net> wrote:
>>>
>>> On 2021-03-04 7:26 p.m., Kazlauskas, Nicholas wrote:
>>>>
>>>> It's a little odd that a disable commit can fail, but I don't think
>>>> there's anything in DRM core that specifies that this can't happen for
>>>> planes.
>>>
>>> I'd say it's more than just a little odd. :) Being unable to disable
>>> an overlay plane seems very surprising, and could make it tricky for
>>> user space (not to mention core DRM code like atomic_remove_fb) to
>>> find a solution.
>>>
>>> I'd suggest the amdgpu DM code should rather virtualize the KMS API
>>> planes somehow such that an overlay plane can always be disabled.
>>> While this might incur some short-term pain, it will likely save more
>>> pain overall in the long term.
>>
>> Yeah I think this amd dc cursor problem is the first case where
>> removing a plane can make things worse.
>>
>> Since the hw is what it is, can't we put a transparent plane with
>> cursor compatible format in for the case where stuff would fail? So
>> not fully virtualize the planes (since I don't see how that helps),
>> but just keeping the plane going underneath it all.

What you describe is one way to "virtualize the KMS API planes", since their state would no longer directly correspond to HW state.


>> I think that's also what Ville did for i915/gen2, which has the
>> requirement that the primary plane must always be on iirc.
>>
>> Ofc since amd display doesn't go through pagetables this needs some
>> vram, but maybe you can use the scalers to make the requirement a bit
>> less drastic.
> 
> The cursor framebuffer would have to be used as the pipe's primary
> framebuffer in this case because the hardware has nothing underneath to
> scan out along with it.
> 
> I'm not sure the atomic async update interface would work well in the
> virtualization case if we had to fallback from using the regular cursor
> programming to using full pipe programming.
> 
> This would burn extra power from the secondary pipe but it would also
> add cursor stuttering into the mix because async updates would be blocked.

Why can't the DM code keep the overlay plane enabled in DC, and make it scan out from a minimal buffer which appears fully transparent, as suggested by Daniel (and yours truly before)?


> My preference would be to continue to reject the commits and not
> implement the fallback path because of how suboptimal the whole thing
> is, but this whole thing is just kind of a mess.

It is indeed. Let's keep the mess contained as much as possible, instead of inflicting it on the whole atomic KMS ecosystem.


-- 
Earthling Michel Dänzer               |               https://redhat.com
Libre software enthusiast             |             Mesa and X developer