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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
