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
