Multiple EGL implementations

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tomas Carnecky wrote:
> 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?

These are two completely different things.  libGLcore / libglx in the
context of my paper is *server side*.  Andy is specifically refering to
libGL which is *client side*.  They are two totally different kettles of
fish.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDaoX5X1gOwKyEAw8RAv9rAKCYIYIH53TixZNW7E7lWANjCdh2CACeLz5N
x/4FGkIixGdHSmJqV2YPQXo=
=y6Hb
-----END PGP SIGNATURE-----