On Tue, 22 Feb 2011 15:04:07 -0800, Ian Romanick <i...@freedesktop.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/22/2011 01:55 PM, Eric Anholt wrote: > > Could the glFlush() skipping affect real applications? I'm not sure if > > ARB_sync or OQ users do glFlush()es after OQs they know they're going to > > use soon, but it's something I wouldn't be surprised by. Right now in > > our driver we're flushing immediately after a sync or OQ end to get > > results sooner, but I sometimes wonder if that's the right thing to be > > doing. > > I believe that all queries have an implicit flush. I think that's the > only way it could work with indirect rendering. Right?
Not according to ARB_oq. Its mention of flushing is that you don't need
to manually glFlush() for polling the query to eventually return ready,
which is not quite the same thing. In fact, in its sample code it's
got:
for (i = 0; i < N; i++) {
glBeginQueryARB(GL_SAMPLES_PASSED_ARB, queries[i]);
// render bounding box for object i
glEndQueryARB(GL_SAMPLES_PASSED_ARB);
}
glFlush();
suggesting that the spec author thinks the driver *wouldn't* flush
automatically, and the app would do it at an opportune time to get a
bunch of batched up queries out the door. If apps worked that way it'd
be awfully nice for us in the driver. At least with the one app I've
tested that has an OQ knob (nexuiz), tweaking the knob doesn't change
performance, but now that I think about it I never tried it in the
non-flushing case so maybe there's actual performance win available.
Here's two hunks of ARB_sync spec:
If the sync object being blocked upon will not be signaled in finite
time (for example, by an associated fence command issued previously,
but not yet flushed to the graphics pipeline), then ClientWaitSync
may hang forever. To help prevent this behavior [fn4], if the
SYNC_FLUSH_COMMANDS_BIT bit is set in <flags>, and <sync> is
unsignaled when ClientWaitSync is called, then the equivalent of
Flush will be performed before blocking on <sync>.
[fn4 - The simple flushing behavior defined by
SYNC_FLUSH_COMMANDS_BIT will not help when waiting for a fence
command issued in another context's command stream to complete.
Applications which block on a fence sync object must take
additional steps to assure that the context from which the
corresponding fence command was issued has flushed that command
to the graphics pipeline.]
[...]
Example of context B waiting on context A:
A: // Create a sync object in the unsignaled state
int props[] = {
OBJECT_SHARED, TRUE,
SYNC_STATUS, UNSIGNALED };
syncObjectA = Sync(SYNC_FENCE, 2, props);
B: // Block, since syncObjectA is in the unsignaled state
ClientWaitSync(syncObjectA);
A: // Perform rendering that B should wait on
render();
// Insert a fence into the command stream. syncObjectA
// remains in the unsignaled state until completion
Fence(syncObjectA);
// To prevent deadlock, A must make forward progress
Flush();
B: // Once the fence command issued above completes, the
// ClientWaitSync issued above will unblock and allow B
// to continue.
(the caveat that appears just before the issue containing this hunk of
spec does not appear to affect the Flush() requirement here.)
So, if your driver puts fences in the batch without flushing, as the
spec authors seem to expect, you have to flush at glFlush() time.
pgpsfjvnm5YlE.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
