Op 30-05-16 om 10:01 schreef Daniel Vetter: > Design ideas: > > - split up the actual commit into different phases, and have > completions for each of them. This will be useful for the future > when we want to interleave phases much more aggressively, for e.g. > queue depth > 1. For not it's just a minimal optimization compared > to current common nonblocking implementation patterns from drivers, > which all stall for the entire commit to complete, including vblank > waits and cleanups. > > - Extract a separate atomic_commit_hw hook since that's the part most > drivers will need to overwrite, hopefully allowing even more shared > code. > > - Enforce EBUSY seamntics by attaching one of the completions to the > flip_done vblank event. Side benefit of forcing atomic drivers using > these helpers to implement event handlign at least semi-correct. I'm > evil that way ;-) > > - Ridiculously modular, as usual. > > - The main tracking unit for a commit stays struct drm_atomic_state, > and the ownership rules for that are unchanged. Ownership still > gets transferred to the driver (and subsequently to the worker) on > successful commits. What is added is a small, per-crtc, refcounted > structure to track pending commits called struct drm_crtc_commit. > No actual state is attached to that though, it's purely for ordering > and waiting. > > - Dependencies are implicitly handled by assuming that any CRTC part > of &drm_atomic_state is a dependency, and that the current commit > must wait for any commits to complete on those CRTC. This way > drivers can easily add more depencies using > drm_atomic_get_crtc_state(), which is very natural since in most > case a dependency exists iff there's some bit of state that needs to > be cross checked. > > Removing depencies is not possible, drivers simply need to be > careful to not include every CRTC in a commit if that's not > necessary. Which is a good idea anyway, since that also avoids > ww_mutex lock contention. > > - Queue depth > 1 sees some prep work in this patch by adding a stall > paramater to drm_atomic_helper_swap_states(). To be able to push > commits entirely free-standing and in a deeper queue through the > back-end the driver must not access any obj->state pointers. This > means we need to track the old state in drm_atomic_state (much > easier with the consolidated arrays), and pass them all explicitly > to driver backends (this will be serious amounts of churn). > > Once that's done stall can be set to false in swap_states. > > Features: Contains bugs because totally untested. > > v2: Dont ask for flip_done signalling when the CRTC is off and stays > off: Drivers don't handle events in that case. Instead complete right > away. This way future commits don't need to have special-case logic, > but can keep blocking for the flip_done completion. > > v3: Tons of fixes: > - Stall for preceeding commit for real, not the current one by > accident. > - Add WARN_ON in case drivers don't fire the drm event. > - Don't double-free drm events. > > v4: Make legacy cursor not stall. > > v5: Extend the helper hook to cover the entire commit tail. Some > drivers need special code for cleanup and vblank waiting, this makes > it a bit more useful. Inspired by the rockchip driver. > > v6: Add WARN_ON to catch drivers who forget to send out the > drm event. > > v7: Fixup the stalls in swap_state for real!! I don't think stalling belongs to swap_state, that should be a separate helper call. When nonblocking = false the waiting is still performed uninterruptibly. I believe that this is an error, and all blocking waiting should be completed before calling swap_state to ensure -EINTR can be propagated correctly as much as possible. Perhaps also return -EBUSY if wait times out. You specified a timeout of 10 HZ, why is that? If we wait interruptibly then there's no need for a timeout. I also think the timeout may be too short, if we commit 3 crtc's it leaves 3.3 seconds for each. In case there's a modeset enable and disable, that leaves 1.6 seconds for each enable/disable. Might be too short.. Patch is also a bit hard to review with so many lines changed, could this be done in pieces instead of all at once? _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
