Re: Linux OpenGL ABI discussion

[Adam J. <aj...@nw...>]

On Thursday 29 September 2005 04:35, Dave Airlie wrote:
> I have to agree with Christoph, the libGL should be a
> one-size-fits-all and capable of loading drivers from any vendor, I'm
> not sure what is so hard about this apart from the fact that neither
> vendor has seemed willing to help out infrastructure on the basis of
> some belief that they shouldn't have to (maybe because they don't on
> Windows) or maybe because they don't want to be seen to collaborate on
> things.... there is hardly any major secrets in the libGL interface
> that should stop it...

There is exactly one "secret": how to go from GL entrypoint to driver dispa=
tch=20
table as fast as possible while still being thread-correct and etc.  Howeve=
r=20
this can be read right out of the compiled object with any reasonable=20
disassembler, so it's not much of a secret.

> As far as I know idr did a lot of work recently on libGL so we can
> expose GL extensions for vendors like ATI without them having to ship
> their own driver (I'm not sure if ATI contributed anything more than a
> list of things needed).. I think he mentioned this was a bit more
> difficult for glx.. but I'm sure it should be possible...

We already had this thread:

http://lists.freedesktop.org/archives/dri-egl/2005-July/000565.html

In particular, Andy's response about why they're uninterested in a common=20
libGL is basically The Last Word on the subject.  It would require that=20
nvidia expend time, effort, and money to get to the same level of=20
functionality they already have.  This applies equally to any other IHV, an=
d=20
to ISVs like XiG and SciTech too for that matter.  You can have whatever=20
opinion you like about that stance, but it's simply an economic reality.

It's also irrelevant.  libGL simply needs to provide ABI guarantees. =20
Specifying driver compatibility is outside the scope of the LSB.

I would make the case that the sonumber for a libGL that supports OpenGL 2.=
0=20
should start with 1.  DSO version numbers are for ABI changes, and OpenGL 2=
=2E0=20
is simply not backwards-incompatible with OpenGL 1.5 for the set of=20
entrypoints they share.  It's not like 2.0 changes the prototype for glEnd(=
)=20
or anything.  So, 1.6.  Or 1.10 or whatever, if we really think that people=
=20
want to do more GL 1.x versions.

I would also make the case that the LSB should in no case require an=20
implementation to have features unavailable in open source.  In particular,=
=20
requiring GL 2.0 would be broken.  Remember what the L stands for here.

The deeper issue here is whether it's actually useful to require some minim=
um=20
level of functionality even when large swaths of it will be software.  If I=
=20
don't have cube map support in hardware, do I really want to try it in=20
software?  Is that a useful experience for developers or for users?

Perhaps what I would like is a new set of glGetString tokens that describe=
=20
what version and extensions the hardware is actually capable of acceleratin=
g,=20
rather than what the software supports.  Because in some sense, advertising=
=20
GL 2.0 on a Riva is so inaccurate as to be worse than lying.

> This is as far as I know how MS's OpenGL ICD system works, there is
> one frontend and your driver can expose extra things via it...

It's not.  MS's MCD (mini client driver) system had something like our curr=
ent=20
system, where you have one GL dispatch layer and the vender provides a driv=
er=20
that gets loaded by the system.  In the ICD scheme, opengl32.dll (or whatev=
er=20
it is) is provided per-vendor.

=2D ajax