On May 16, 2005, at 12:31 PM, Haroon Sheikh wrote:
Tiger's auto-beam-sync has ~bugs~. It does not work properly;
hopefully it will be fixed soon. It should have been obvious that
forcing a blocking implementation was the wrong approach...
What are the bugs and if you haven't already, please file a bug
report. It will only be fixed if you filed a bug report.
<rdar://problems/3566400> GL_APPLE_flush_render problems *
<rdar://problems/3566403> GL_APPLE_flush_render enhancement **
<rdar://problems/4075545> 10.4.1 (8B9) general performance - sluggish
<rdar://problems/4103784> 10.3 (7W98) - QT 7.0 poor CoreVideo
performance
<rdar://problems/4110581> OpenGL glFlush/glFlushRenderAPPLE take 5x
longer on Tiger
<rdar://problems/4113808> QuartzCore.framework can't be weak_linked,
10.3.9 SDK incompatibility
<rdar://problems/4119986> 10.4.1 (8B15) - Quartz CGS enforces auto-
beam-sync for ALL app's
Last year at WWDC, I explained the idea for my enhancement to CGS:
enqueueing all dirty surfaces which have been rendered, and blitting/
swapping at VBL en masse, which now seems to have been partially
incorporated. The problem is that we can't have the blocking
behavior extended into the current APIs, because it fails for the
same reason NSOpenGLCPSwapInterval doesn't work well for that
purpose, and why developers avoid glFinish.
GL_APPLE_flush_render "wants to take the correct approach", but
_needs_ to be extended using the enhancement I suggested, as I
explained in the WWDC graphics lab last year where I demoed the
MacFOH synchronizer (Alex Eddy added a red/black surface swap plug-in
to illustrate the sync which would only tear if CGS compositing were
in effect), and I outlined my idea for global beam syncing by CGS.
We already have the VBL callback in CVDisplayLink, which is nearly
identical to the MacFOH sync, but it feels "looser" when in use,
partly because of CV's lower thread priority plus its latency
estimation smoothing. Okay, now were getting somewhere...
What we don't have is a VBL swap-completion callback, which should be
per-surface in granularity.
As it is, the blocking behavior is enforced for all apps (which might
be another bug, since it's only supposed to affect executables linked
against Tiger, correct?), but the way it blocks is wrong, IMO. By
NOT blocking when a surface is submitted, an untethered rendering
loop will immediately begin to construct the next frame, which most
likely will be using the same data as the frame it just submitted for
flushing. To enforce sync using that API means that it must block
immediately (ie glFinish + sync), and not begin rendering again until
the frame has been displayed. If I allow this freewheeling to occur
(ie not using my own sync), then the app renders at exactly 2.5 times
the VBL rate, using Tiger's current approach. The first frame is
rendered, flushed (which doesn't block), then it can be rendered
again as soon as new data is available, usually before the previous
frame has been flushed, and then it renders and flushes again,
blocking. Bad! This results in inconsistent and poor input-to-pixel
latency (re an audio analyzer), always lagging 1 or 2 frames.
The melding of render + flush is not a good idea. The two functions
need to be separate. What I requested 2 years ago as an enhancement
would provide a means to accomplish global beam sync without
affecting existing app's. **
Currently, glFlushRenderAPPLE() causes all commands to be executed,
but does not execute a swap (if double buffered) or flush (single-
buffered blit to screen). This works well. glFlushSwapAPPLE() works
ONLY for double-buffered contexts, and does nothing for single-
buffered contexts. *
I proposed an enhancement to that extension with two new functions,
which could be provided by CGS thru the various API's internally, and
to GL as follows:
glSwapSyncAPPLE() - a non-blocking function to enqueue the
current context/drawable to be automatically swapped at the next VBL,
after it has finished (without blocking the caller of course).
Subsequent submissions of the same swap-pending context would be
ignored.
glWaitSyncAPPLE(GLint interval) - a blocking function which will
return only after an enqueued swap's completion, or returns
immediately if no swap is pending. It will not initiate a flush/
finish/swap. This can be used to synchronize app threads. Interval
would be 0 to return immediately if none pending, or N to wait until
after the next N VBL intervals, which would block indefinitely until
after the N'th subsequent VBL (and after the next swap was submitted
and subsequently finished), etc. This would sync to the drawable's
virtual screen, and the display device containing the majority of the
drawable. For off-screen, pbuffers, etc, interval would have no sync
effect except to block until N swap completions. Using N = -1 would
block until the next -N VBL intervals, regardless of pending swap
status.
--
Shaun Wexler
MacFOH http://www.macfoh.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartz-dev/email@hidden
