Multiple EGL implementations

[Tomas Carnecky]

Andy Ritger wrote:
> 
> However, Keith is right: for immediate-mode OpenGL applications,
> the overhead of API dispatching is very significant.  Dispatching
> through a common libGL is very undesirable for this (unfortunately
> still quite common) usage case.
> 
> While I admit that having a common libGL and allowing multiple vendor
> implementations to coexist is a noble goal, from a strictly IHV
> standpoint this is not interesting (for obvious business reasons).

Ian Romanick has written a nice paper about the future of GLX and the 
OpenGL library: http://www.cs.pdx.edu/~idr/publications/
He writes:
  o Add support for dynamically loading per-screen “libGLcore”

We are not far away from workstations with several 8x-PCI-Express (PEG) 
slots which will allow us put several graphics cards into one computer. 
I'm pretty sure we will see mainboards with 2-4 PEG slots followed by 
computer-clusters with those mainboards, 2-4 graphics cards in each 
computer crunching numbers on the GPUs. The GPU is much much faster for 
certain computations then even the fastest CPU! And at that point, you 
will have to give the user the choice to put GPUs from different vendors 
into one computer.
So.. how do you see the future of a dynamic libGLcore?

tom