Multiple EGL implementations

[Jon Smirl]

On 7/2/05, Adam Jackson <ajax at nwnk.net> wrote:
> On Saturday 02 July 2005 12:28, Jon Smirl wrote:
> > On 7/2/05, Adam Jackson <ajax at nwnk.net> wrote:
> > > On Saturday 02 July 2005 12:12, Jon Smirl wrote:
> > > > How are we going to sort out multiple implementations of libGL?
> > >
> > > By not having them.
> > >
> > > Anything else is a hack.
> >
> > So no mixing Nvidia/ATI proprietary and DRI cards in the same system?
> > ATI is building PCI Express chipsets which explicitly support cards
> > from mixed vendors.
> 
> You missed it.  libGL, by any sane definition, should be a common object that
> no vendor replaces [1].  That it's not is a major bug.

And this bug is going to get fixed? Probably about the same time
Nvidia sends us specs for their chips. I didn't miss it, I didn't
think it was fixable.

> There's known workarounds for that, aging back at least as far as linuxdoom,
> where the client app dlopen's the libGL it wants.  dlmopen means you get
> separate namespaces for each too, so there's no chance of global symbols
> stomping each other.  So it's a tractable problem above the library layer.

That's why I was cc'ing David Reveman. I thought that it probably had
to go into Xgl but I was poking around to see if there was hope of a
better solution.

Adding a multiplexer to Xgl opens up a couple of neat features. We can
support mixed ATI/Nvidia/DRI systems. Xgl can also implement a GLX
protocol client as a multiplexer option. That would allow Xgl to
function like DMX and assemble display walls. Of course we will need
to modify GLX to transmit the EGL calls.

> But this is no longer 1995, and that's not the right solution.  Implement it
> in Xgl if you want, but it doesn't belong in the library layer.  Yes, this
> means evangelizing to the vendors to get libGL in a sharable state.

I have wasted too much time talking to brick walls. You can talk to
them if you want.

> [1] - excluding things like early support for new extensions, of course.
> 
> - ajax
> 
> 
> 


-- 
Jon Smirl
jonsmirl at gmail.com