[Piglit] [PATCH 2/2] EGL_CHROMIUM_get_sync_values: Add conformance test.

[Chad Versace]

On Thu, Apr 24, 2014 at 09:17:50AM -0700, Jamey Sharp wrote:
> On Apr 23, 2014 1:36 PM, "Chad Versace" <chad.versace at linux.intel.com> wrote:
> > On Tue, Apr 22, 2014 at 12:22:12PM -0700, Sarah Sharp wrote:
> > > On Fri, Apr 18, 2014 at 06:21:31PM -0700, Jamey Sharp wrote:
> > > > - I don't see that MSC has to change at all even after two
> > > > eglSwapBuffers calls, if SwapBuffers doesn't sync to vertical retrace.
> > >
> > > I looked at the EGL 1.5 spec with Chad, and if you look at the
> > > definition of eglSwapInterval, you'll see that the "minimum number of
> > > video frame periods per buffer swap" is set to 1 by default.  I think
> > > one frame period is the time between vertical retraces, but the spec
> > > isn't clear on that.
> >
> > The spec is sadly ambiguous on that. It's also ambiguous on whether
> > eglSwapBuffers blocks or immediately returns false if too many
> > outstanding swaps are pending.
> >
> > I think it's safe to assume that it blocks.  because that's what all EGL
> > implementations do that I've used: X11, Android, Wayland, and
> > (vacuously) GBM. (More below on why this it's vacuously true that GBM
> > implements the blocking behavior).
> 
> I'd just feel more comfortable, in a conformance test, if there were
> specification text you could point to instead of a de facto standard. I note
> you only mention Linux based GL implementations, after all.

All Linux, but not all Mesa. Android's eglSwapBuffers is supposed to block
across all Android platforms.

On the Khronos EGL Teleconference yesterday, several EGL vendors coincidentally
had a lengthy conversation about bugs that arise in applications due to
eglSwapBuffers undesirably blocking. (The conversation's motivation was not
this Piglit test, though). An implicit axiom that underpinned the conversation
was that eglSwapBuffers does block. That's just what implementations do. The
blocking itself wasn't up for debate, but how applications should deal with it
rare corner cases.

So I stand by my claim. The de facto standard is the standard here.

> > As for eglSwapBuffers being synchronized to vertical retraces, again it
> > is on all platforms I've used.
> 
> Modulo bugs, presumably, since it certainly isn't reliably synchronized in X
> right now. :-) But I agree that it's intended to be, especially considering:

How is it not synchronized in X? And how unreliabe is its unreliability?
Please tell. This storm cloud troubles my soul.

> Theo has since pointed out this sentence in the OML_sync_control spec:
> 
> "If there are multiple outstanding swaps for the same window, at most one such
> swap can be satisfied per increment of MSC."
> 
> So I retract my first concern. :-)
> 
> (Technically this doesn't say the swap has to happen during vertical retrace,
> but for the purposes of Sarah's tests that doesn't matter.)

I found the EGL text that mandates synchronization to vertical retrace! From
the EGL 1.5 spec:

  If interval is set to a value of 0, buffer swaps are not synchronized to a
  video frame, [...]

Well sorta... Though not explicitly stated, I believe spec clearly intends to
mandate the inverse also: "If the invterval is non-zero, buffer swaps are
synchronized to a video frame".

> > I played with that test app on X11, Wayland, and GBM to discover exactly
> > how the swap interval behaves on each platform. Wayland was the
> > weirdest.
> 
> Out of curiosity, how was Wayland weird?

The swap interval range in Wayland is [EGL_MIN_SWAP_INTERVAL=0, EGL_MAX_SWAP_INTERVAL=1].
I was surprised that EGL_MAX_SWAP_INTERVAL < 2.

> > I think the test should do this:
> >
> >     Create the EGLConfig as it currently does. That is, do not specify
> >     EGL_[MIN|MAX]_SWAP_INTERVAL.  Then immediately query
> >     eglGetConfigAttrib(EGL_MIN_SWAP_INTERVAL) and
> >     eglGetConfigAttrib(EGL_MAX_SWAP_INTERVAL).
> >
> >     If the max swap interval is 0, then eglSwapBuffers will not block.
> >     So report PIGLIT_RESULT_SKIP.
> >
> >     Else, the EGL spec ensures that the surface's swap interval is
> >     EGL_MIN_SWAP_INTERVAL. Calculate the expected MSC and SBC from that.
> >
> >     For bonus points, let the desired swap_interval be an input
> >     parameter to the test. The test will skip if and only if
> >     requested_swap_interval is outside of [EGL_MIN_SWAP_INTERVAL,
> >     EGL_MAX_SWAP_INTERVAL]. The test sets the surface's swap interval
> >     with eglSwapInterval(requested_swap_interval), calculates expected
> >     values of of MSC and SBC, and tests for them.
> >
> > Why is GBM a special case? Because EGLConfigs on GBM have
> > EGL_MIN_SWAP_INTERVAL == EGL_MAX_SWAP_INTERVAL == 0. So eglSwapBuffers
> > never throttles.
> 
> This strikes me as a very satisfying way to handle it, my lingering concerns
> about unspecified throttling/blocking behavior notwithstanding.
> 
> Ooh, and does Mesa set EGL_MAX_SWAP_INTERVAL == 0 if vblank_mode is 0?

Yep. This code block, present in the X11 and Wayland code, does it. I verified
it actually does it job with my wfl-swapinterval toy.

   switch (vblank_mode) {
   case DRI_CONF_VBLANK_NEVER:
      dri2_dpy->min_swap_interval = 0;
      dri2_dpy->max_swap_interval = 0;
      dri2_dpy->default_swap_interval = 0;
      break;
   case DRI_CONF_VBLANK_ALWAYS_SYNC:
      dri2_dpy->min_swap_interval = 1;
      dri2_dpy->max_swap_interval = arbitrary_max_interval;
      dri2_dpy->default_swap_interval = 1;
      break;                                                                                                                                            
   case DRI_CONF_VBLANK_DEF_INTERVAL_0:
      dri2_dpy->min_swap_interval = 0;
      dri2_dpy->max_swap_interval = arbitrary_max_interval;
      dri2_dpy->default_swap_interval = 0;
      break;
   default:
   case DRI_CONF_VBLANK_DEF_INTERVAL_1:
      dri2_dpy->min_swap_interval = 0;
      dri2_dpy->max_swap_interval = arbitrary_max_interval;
      dri2_dpy->default_swap_interval = 1;
      break;
   }