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

[Jakob Bornecrantz]

On Thu, Apr 25, 2013 at 9:59 PM, Andy Ritger <aritger at nvidia.com> wrote:

> 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.
>

The libEGL.so code in Mesa might not be exactly what you are looking for,
the current dispatching is more like mesas internal driver dispatching then
libGL.so straight up dispatching, as it validates some of the inputs, it
also
assumes a bit about the layout of certain structs and as such requires you
write the driver against the is not opaque that interface is not ABI stable
either. So think you will have to write the dispatching part from scratch to
make it more just directly dispatch into the driver like libGL does.

You can probably reuse some of the per thread state code from there tho
since that needs to be in the libEGL implementation. I'm also uncertain
about the loader code but it might be worth a look.

Cheers, Jakob.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130425/2bb282da/attachment.html>