On Apr 23, 2014 1:36 PM, "Chad Versace" <<a href="mailto:chad.versace@linux.intel.com">chad.versace@linux.intel.com</a>> 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