Correct sequencing of usage of DRM writeback connector

[Abhinav Kumar]

Hi

On 6/17/2024 9:54 AM, Brian Starkey wrote:
> Hi,
> 
> On Mon, Jun 17, 2024 at 05:16:36PM +0200, Daniel Vetter wrote:
>> On Mon, Jun 17, 2024 at 01:41:59PM +0000, Hoosier, Matt wrote:
>>> Hi,
>>>
>>> There is a discussion ongoing over in the compositor world about the implication of this cautionary wording found in the documentation for the DRM_MODE_CONNECTOR_WRITEBACK connectors:
>>>
>>>>   *  "WRITEBACK_OUT_FENCE_PTR":
>>>>   *	Userspace can use this property to provide a pointer for the kernel to
>>>>   *	fill with a sync_file file descriptor, which will signal once the
>>>>   *	writeback is finished. The value should be the address of a 32-bit
>>>>   *	signed integer, cast to a u64.
>>>>   *	Userspace should wait for this fence to signal before making another
>>>>   *	commit affecting any of the same CRTCs, Planes or Connectors.
>>>>   *	**Failure to do so will result in undefined behaviour.**
>>>>   *	For this reason it is strongly recommended that all userspace
>>>>   *	applications making use of writeback connectors *always* retrieve an
>>>>   *	out-fence for the commit and use it appropriately.
>>>>   *	From userspace, this property will always read as zero.
>>>
>>> The question is whether it's realistic to hope that a DRM writeback
>>> connector can produce results on every frame, and do so without dragging
>>> down the frame-rate for the connector.
>>>
>>> The wording in the documentation above suggests that it is very likely
>>> the fence fd won't signal userspace until after the vblank following the
>>> scanout during which the writeback was applied (call that frame N). This
>>> would mean that the compositor driving the connector would typically be
>>> unable to legally queue a page flip for frame N+1.
>>>
>>> Is this the right interpretation? Is the writeback hardware typically
>>> even designed with a streaming use-case in mind? Maybe it's just
>>> intended for occasional static screenshots.
>>
>> So typically writeback hardware needs its separate crtc (at least the
>> examples I know of) and doesn't make a lot of guarantees that it's fast
>> enough for real time use. Since it's a separate crtc it shouldn't hold up
>> the main composition loop, and so this should be all fine.
> 
> On Mali-DP and Komeda at least, you can use writeback on the same CRTC
> that is driving a "real" display, and it should generally work. If the
> writeback doesn't keep up then the HW will signal an error, but it was
> designed to work in-sync with real scanout, on the same pipe.
> 

Same with MSM hardware. You can use writeback with same CRTC that is 
driving a "real" display and yes we call it concurrent writeback. So I 
think it is correct in the documentation to expect to wait till this is 
signaled if the same CRTC is being used.

>>
>> If/when we have hardware and driver support where you can use the
>> writeback connector as a real-time streamout kind of thing, then we need
>> to change all this, because with the current implementation, there's
>> indeed the possibility that funny things can happen if you ignore the
>> notice (funny as in data corruption, not funny as the kernel crashes of
>> course).
> 
> Indeed, the wording was added (from what I remember from so long
> ago...) because it sounded like different HW made very different
> guarantees/non-guarantees about what data would be written when, so
> perhaps you'd end up with some pixels from the next frame in your
> buffer or something.
> 
> Taking Mali-DP/Komeda again, the writeback configuration is latched
> along with everything else, and writeback throughput permitting, it
> should "just work" if you submit a new writeback every frame. It
> drains out the last of the data during vblank, before starting on the
> next frame. That doesn't help the "general case" though.
> 

Would it be fair to summarize it like below:

1) If the same CRTC is shared with the real time display, then the 
hardware is expected to fire this every frame so userspace should wait 
till this is signaled.

2) If a different CRTC is used for the writeback, then the composition 
loop for the real time display should not block on this unless its a 
mirroring use-case, then we will be throttled by the lowest refresh rate 
anyway.

>>
>> If we already have devices where you can use writeback together with real
>> outputs, then I guess that counts as an oopsie :-/
> 
> Well "works fine" fits into the "undefined behaviour" bucket, just as
> well as "corrupts your fb" does :-)
> 
> -Brian
> 
>>
>> Cheers, Sima
>> -- 
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch