Am Donnerstag, den 04.05.2017, 11:17 +0200 schrieb Daniel Vetter: > On Thu, May 4, 2017 at 11:12 AM, Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote: > > Am Donnerstag, den 04.05.2017, 10:02 +0100 schrieb Daniel Stone: > >> On 4 May 2017 at 09:59, Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote: > >> > Am Mittwoch, den 03.05.2017, 18:15 +0100 schrieb Daniel Stone: > >> >> What about planes which aren't present in this commit, but are still > >> >> taking up a PRE unit? Will they have their PRE stolen, or am I missing > >> >> something? > >> > > >> > Yes, the plane->PRE assignment is configurable by matching different AXI > >> > IDs in the PRG. So what's happening here is that we basically construct > >> > a new assignment for each commit. Planes without a assigned PRE will > >> > revert back to pass-through mode in the PRG on plane commit or plane > >> > disable. > >> > >> So those other planes are fine/untouched, because the PRE has already > >> resolved to linear? Specifically if plane A has a tiled FB, then > >> userspace does a commit which _only_ contains plane B (also with a > >> tiled FB), and plane B steals the PRE that was previously assigned to > >> plane A, then plane A continues displaying just fine? Sorry for the > >> stupid questions. :) > > > > If userspace does a commit with only plane B it's going to disable plane > > A, right? The PRG/PRE register sets are double buffered (or at least we > > always use them in this mode). So if plane B steals the PRE from plane > > A, which is going to get disabled, plane A will continue to use the PRE > > until the end of frame, then the register set will be latched and the > > PRE is switched to plane B for the next frame. > > Atomic is incremental, if a property is unchanged it's supposed to > keep as-is. Same with entire objects. > > What's more, did you wire up the fb->dirty hook to make sure this > stuff gets flushed correctly for frontbuffer rendering? Userspace is > allowed to render into the current frontbuffer using gl, call all the > flush/clear stuff and then call the DIRTY_FB ioctl, and things are > supposed to show up on the screen. There's some ideas from the simple > pipe helpers to essentially unify frontbuffer flushing and treat it > like any atomic commit. The PREs are stream processors, they are only prefetching (and resolving) a few scanlines to internal SRAM. Any rendering to the frontbuffer will properly show up without any additional dirty tracking. You can think of the PREs as slightly bigger display FIFOs. > tldr; you need a PRE for all planes, you're looking for > drm_atomic_add_affected_planes() to make sure all planes are in the > update. Thanks, I'll look at this. Regards, Lucas _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
