[Mesa-dev] Proposal for an Updated Linux OpenGL ABI, again

[Andy Ritger]

On Thu, Apr 25, 2013 at 05:34:11AM -0700, Ian Romanick wrote:
> On 04/25/2013 11:12 AM, Andy Ritger wrote:
> > Hi all,
> >
> > Last fall, I put together a proposal for an updated Linux OpenGL ABI
> > specification:
> >
> >      https://github.com/aritger/linux-opengl-abi-proposal/blob/master/linux-opengl-abi-proposal.txt
> >
> > but then got distracted.  I'd like to try to resurrect the discussion.
> >
> >  From the earlier email thread and some discussion at XDC2012, it sounded
> > like people thought the general ideas were reasonable.  However, there are
> > a variety of details to work through, called out in the issues section.
> >
> > To get things moving, I thought I, and a few others from NVIDIA, would
> > try to prototype some of the vendor-neutral API Libraries described in the
> > document.  That might give us all something more concrete to play with.
> >
> > Feedback on anything in the full proposal welcome, but here are a few
> > more specific questions:
> >
> > * For a prototype, what is a reasonable version of OpenGL to provide
> >    in libOpenGL.so.1?  There are a variety of options enumerated in the
> >    full proposal for how to handle sets of entry points, but my sense is
> >    that the simplest solution is for libOpenGL.so.1 to provide a reasonable
> >    base version of OpenGL, and then all entry points for extensions and
> >    later OpenGL versions to be accessed through {egl,glX}GetProcAddress.
> 
> If it's just the availability of the entry points (w/o using 
> GetProcAddress), I don't see any reason to include less than 4.3 + every 
> ARB extension.

Thanks, Ian.

Yes, this is just about the availability of entry points as symbols in
the DSO.  It sounds good to me to cast a wide net and export a large
set of symbols.

Do you have a vision for any upgrade of that set of symbols?  My hope
is that libOpenGL.so.1 will be maintained/distributed independently of
any specific vendor's OpenGL implementation.  Maybe in an ideal world
it would get revved everytime Khronos releases a new OpenGL version,
or a new ARB extension is ratified.  But, then we need to worry about
(a) someone keeping it up to date, and (b) handling the version number
in libOpenGL.so's SONAME, so that an application can express which
symbols it expects the DSO to provide.

Given tools like GLEW, it may be easier for applications to just assume
whatever fixed list we lock down initially for the new ABI, and then
use GetProcAddress for everything else.

I don't think we need to decide, yet, how frequently to update the
exported symbol list from libOpenGL.so.  But, it is probably worthing
thinking about, if we define in the ABI that libOpenGL.so will export
symbols for 4.3 + every ARB extension, as of April 25, 2013.

> > * From some initial reading, Mesa's glapi (src/mapi/glapi/) looks useful
> >    for the basis of libOpenGL.so.1's dispatching.  Would it be reasonable
> >    to use glapi in the prototype libOpenGL.so.1?
> 
> Yes.
> 
> > * The vendor-neutral libEGL.so.1 is intended to be a thin layer that
> >    would dispatch to the appropriate vendor.  It looks like the frontend of
> >    Mesa's EGL implementation would be a good basis for the vendor-neutral
> >    libEGL.so.1.  Would it be reasonable to use that for the prototype?
> 
> Yes.  There is already mechanism to control which backend gets 
> dispatched within libEGL.so.  It shouldn't be too hard to make it 
> discover additional .so files containing additional backends.  Kristian 
> may have some ideas about how to do that.

Sounds good.

Thanks,
- Andy

> > Thanks,
> > - Andy
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>