multiple local and remote displays

[Brian Paul]

Jon Smirl wrote:
> How should we handle these setups?
> 
> 1) local display, multiple incompatible OpenGL stacks

The EGL application would have a separate EGLDisplay handle for each card.


> 2) simultaneous use of local and remote displays

A separate EGLDisplay handle for each local and each remote display.


> 3) N local cards rendering to N monitors composing a single display

That's outside the scope of EGL [low-level EGL anyway, more below] 
since there are three separate framebuffers / graphics pipes.  Another 
software layer would be used to broadcast drawing commands, etc. to 
those separate pipes.


> 4) N remote machines each with a GL stack composing a single display

Same as 3.


> I would like all of these cases to be transparent to the app. But
> there needs to be some kind of configuration for how the displays are
> put together.
> 
> The solution is probably a layer above the current egl proposal like
> Chronium but we should design the local egl API so that the insertion
> of this layer is transparent.

Correct- a higher layer would do that.  I wouldn't use Chromium though.

If the EGL API/library is written correctly it will allow this.  For 
example, a particular EGL driver would act in a DMX-like manner and 
allow a collection of child EGL implementations to appear as one to 
the application.

The EGL dispatch mechanism I've prototyped will support this.


> Neat example would be a presentation wall with nine monitors each with
> a machine and OpenGL stack. Now it is your turn to present. You attach
> to the wall and clone your local display onto it. The wall would just
> look like another screen to the local machine. The local machine would
> have to be smart enough to send the OpenGL stream to the nine
> machines.

Right.

-Brian