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

[Jamey Sharp]

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.

Any day one can use a word like "vacuously" is a good day, though.

> 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:

> Like Sarah said. If you set env vars that provide nonconformant
> behavior, then your conformance testsuite may fail.

It wasn't obvious to me that that was non-conforming behavior. However,
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 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?

> 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?

Jamey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20140424/d6c937e6/attachment.html>