[Mesa-dev] [PATCH 2/4] atomic: Use CPU-side KMS fence synchronisation

[Chris Wilson]

On Tue, May 02, 2017 at 12:34:44PM +0100, Daniel Stone wrote:
> Hi,
> 
> On 2 May 2017 at 12:31, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > On Tue, May 02, 2017 at 11:52:07AM +0100, Daniel Stone wrote:
> >> +                     /* Wait on the CPU side for the _previous_ commit to
> >> +                      * complete before we post the flip through KMS, as
> >> +                      * atomic will reject the commit if we post a new one
> >> +                      * whilst the previous one is still pending.
> >> +                      */
> >> +                     do {
> >> +                             status = egl->eglClientWaitSyncKHR(egl->display,
> >> +                                                                kms_fence,
> >> +                                                                0,
> >> +                                                                EGL_FOREVER_KHR);
> >> +                     } while (status != EGL_CONDITION_SATISFIED_KHR);
> >> +
> >> +                     egl->eglDestroySyncKHR(egl->display, kms_fence);
> >
> > Would it be an interesting exercise to use that as the in-fence for the GPU?
> > Not sure which is more in the spirit of kmscube.
> 
> Er, it already does so, in the first hunks this patch touches.

Ok! I was just expressing my concern in case it was accidentally 
synchronising the GPU execution as well. In which case that explains why
it works for msm and fails for i915, as msm will synchronously wait for
its in-fence before executing and returning from the submit ioctl.
 
> They are solving different issues though. We need to block on the GPU,
> to ensure the GPU does not start rendering to the buffer whilst it is
> still in use. But we also need to block on the CPU to ensure that we
> do not try to submit an atomic commit before the previous atomic
> complete has committed, since here we are not using pageflip events at
> all, but solely relying on fences as our synchronisation mechanism.

Do we expose the maximum presentation queue depth or is that hardcoded to
1 in the KMS ABI right now?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre