[Mesa-dev] [PATCH 3/4] dri2: Don't call the dri2 flush hook for swapbuffers unless we have a context.

[Eric Anholt]

On Tue, 22 Feb 2011 15:04:07 -0800, Ian Romanick <idr at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110222/47d3d60d/attachment-0001.pgp>