On Tue, May 02, 2017 at 12:34:44PM +0100, Daniel Stone wrote: > Hi, > > On 2 May 2017 at 12:31, Chris Wilson <[email protected]> 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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
