<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 02/20/2013 09:27 PM, Keith Packard
wrote:<br>
</div>
<blockquote cite="mid:86r4kavigz.fsf@miki.keithp.com" type="cite">
<pre wrap="">Chris Wilson <a class="moz-txt-link-rfc2396E" href="mailto:chris@chris-wilson.co.uk"><chris@chris-wilson.co.uk></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">What I don't see here is how the client instructs the server to
handle a missed swap.
</pre>
</blockquote>
<pre wrap="">
Right, this first pass was just trying to replicate the DRI2 semantics;
figuring out how to improve those seems like a good idea.
>From what game developers have told us, a missed swap should just tear
instead of dropping a frame. It might be nice to inform the client that
they're not keeping up with the target frame rate and let them scale
stuff back; I'd suggest the SwapComplete event could contain enough
information to let them know what actually happened.
</pre>
</blockquote>
<br>
Please make this configurable. Tearing makes sense for a game, but
for the kind of scientific apps i do, we don't want it to tear ever,
or bad things would happen for us. We need it to just flip the frame
delayed but vsync'ed and then the app can figure out via the
INTEL_swap_events or glXWaitForSbcOML() that a deadline was missed
and what to do to catch up.<br>
<br>
There's
<a class="moz-txt-link-freetext" href="http://www.opengl.org/registry/specs/EXT/glx_swap_control_tear.txt">http://www.opengl.org/registry/specs/EXT/glx_swap_control_tear.txt</a>
that allows apps to define if they want to tear or vsync on a missed
swap deadline.<br>
<br>
<blockquote cite="mid:86r4kavigz.fsf@miki.keithp.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">For example, with the typical use of
swap-interval > 0, divisor = 0, target <= current
we can choose to either emit this SwapRegion synchronously, or
asynchronously (to risk tearing but allow the client catch up to its
target framerate).
</pre>
</blockquote>
<pre wrap="">
I haven't heard anyone asking for us to skip a frame in this case to
avoid tearing.
</pre>
</blockquote>
<br>
See above :-).<br>
<br>
...
<pre wrap=""> In the reply, swap_hi/swap_lo form a 64-bit swap count value
when the swap will actually occur (e.g. the last queued swap
count + (pending swap count * swap interval)).
</pre>
<blockquote cite="mid:86r4kavigz.fsf@miki.keithp.com" type="cite">
<blockquote type="cite">
<pre wrap="">t
I'm not sure exactly what SBC is meant to be. Is it a simple seqno of
the SwapRegion in this Drawable's swap queue (why then does
swap_interval matter), or is it meant to correlate with the vblank
counter (in which case it is merely a predicted value)?
</pre>
</blockquote>
<pre wrap="">
Just like DRI2, it's the planned swap time. Don't be late!
</pre>
</blockquote>
<br>
SBC in DRI2 is the running count of completed swaps for a drawable,
ie., current swap count + pending swap count, not the planned swap
time. Essentially a reference to a just queued swap via sbc =
glXSwapBuffersMscOML(...), so you can use sbc as a unique id for
that swap in glXWaitForSBCOML() or to match it up with the sbc in a
returned INTEL_swap_event. Very useful, so i guess this should stay
backwards-compatible.<br>
<br>
thanks,<br>
-mario<br>
<br>
<blockquote cite="mid:86r4kavigz.fsf@miki.keithp.com" type="cite">
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:xorg-devel@lists.x.org">xorg-devel@lists.x.org</a>: X.Org development
Archives: <a class="moz-txt-link-freetext" href="http://lists.x.org/archives/xorg-devel">http://lists.x.org/archives/xorg-devel</a>
Info: <a class="moz-txt-link-freetext" href="http://lists.x.org/mailman/listinfo/xorg-devel">http://lists.x.org/mailman/listinfo/xorg-devel</a></pre>
</blockquote>
<br>
</body>
</html>