Allen Akin wrote:
> On Thu, Oct 11, 2007 at 10:35:28PM +0100, Keith Whitwell wrote:
> | Suppose 2 clients render to the same backbuffer...
> 
> The (rare) cases in which I've seen this used, the clients are aware of
> one another, and restrict their rendering to non-overlapping portions of
> the drawable.  A "master" client is responsible for swap and clear.
> 
> I believe the intent of the spec was to allow CPU-bound apps to make use
> of multiple processors.  Rendering to a single drawable, rather than
> multiple drawables, allowed swap to be synchronized.
> 
> I recall discussions about ways to coordinate multiple command streams
> so that rendering to overlapping areas of the drawable could be handled
> effectively, but I don't remember any apps that used such methods.

Allen,

Just to clarify, would things look a bit like this:

Master:
        clear,
        glFlush,
        signal slaves somehow

Slave0..n:
        wait for signal,
        don't clear, just draw triangles
        glFlush
        signal master

Master:
        wait for all slaves
        glXSwapBuffers

This is fairly sensible and clearly requires a shared buffer.  It's also 
quite a controlled situation that sidesteps some of the questions about 
what happens when two clients are issuing swapbuffers willy-nilly on the 
same drawable at the same time as the user is frantically resizing it...

Keith

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to