Correct sequencing of usage of DRM writeback connector

[Brian Starkey]

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.

>
>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.

>
>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