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