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

Andy Ritger aritger at nvidia.com
Fri Sep 14 17:07:37 PDT 2012


On Fri, Sep 14, 2012 at 12:17:26AM -0700, Ian Romanick wrote:
> On 09/13/2012 12:09 AM, Andy Ritger wrote:
> > There was some recent Khronos discussion about updating the OpenGL
> > Implementer's Guide for Linux, to which Ian Romanick noted that this
> > topic will be discussed at XDC as part of the broad "Discuss the future
> > of EGL, GLX, and OpenGL ES on Linux" agenda item.
> >
> > To help facilitate the XDC discussion, I've put together a straw-man
> > proposal for an updated Linux OpenGL ABI.  I'm sending this out now to
> > start generating feedback and ideas, to help make the XDC discussion as
> > productive as possible.
> 
> Wow.  This is a really thorough proposal.  Thank you for taking the time
> to put this together.  Will you be at XDC?  I look forward to talking to
> you more there.

Thanks, Ian.  Yes, I'll be at XDC.  The OpenGL ABI discussion is the
primary topic for me at XDC.  It should be a good conference.

> I'm still working my way through this, but I have some comments now.  I
> should have quite a bit more by XDC next week.

Responses below:

> >      Option (c): Return entry points for all GetProcAddress'ed strings.  In this
> >          model, the API library would use logic like this:
> >
> >          * Does a dispatch function already exist for the string passed
> >            into GetProcAddress?  If so, return that.
> >          * Else, online generate a dispatch function for the given string.
> >            Default the dispatch table to a noop function.
> >          * At MakeCurrent time, the vendor library would provide all
> >            the strings/function pointers that it supports and the API
> >            library would need to plug those vendor functions into the
> >            online-generated entry points.  I.e., effectively "lazily
> >            resolve" at MakeCurrent time.
> >
> >          Pros:
> >              * Does not require loading vendor libraries before the vendor
> >                library would be otherwise needed.
> >          Cons:
> >              * Some complexity at MakeCurrent time to map the
> >                GetProcAddress'ed entry points to the vendor functions.
> >              * This would break apps who determine if a feature is
> >                available via GetProcAddress (though such apps are broken:
> >                they are supposed to check the extension string, per [6]).
> 
> This is the model we have now.  If we make libOpenGL largely fixed in
> time, I think this is the only model that could work.  Right?  If we
> ship a libOpenGL now, how can we know what extensions some vendor
> library will have in 2 months?

Agreed.

> >      (3) How should Window System (GLX,EGL) API functions work with
> >          {glX,egl}GetProcAddress?  GetProcAddress is supposed to return
> >          context-independent functions.  For client-API functions,
> >          dispatching can always be done based on the current context,
> >          but window system layer functions must be dispatched differently
> >          depending on the arguments they take.  It isn't clear how to
> >          dispatch a window system layer function without knowledge of
> >          its parameters.
> 
> This has always been a trouble spot for Mesa.  A lot of the guts of GLX
> data structures are shared, so having per-vendor library functions has
> been all but impossible.  In practice, I'm not really sure this is a
> problem.  The part of the implementation in the GLX (or EGL) library is
> generally very thin, and it is usually just a bunch of GLX protocol
> handling code.
> 
> We ought to be able to define shared interfaces between the API
> libraries and the vendor libraries in a similar way.  This means that
> users may need to get updated API libraries to have access to all the
> functionality in the vendor library, but it should simplify the
> implementations of each enough to make it worth it.

If we can do it without too much complexity, I'd like to avoid needing
to update the API libraries too often.  A lot of workstation customers
are pretty conservative with their distro upgrades, so it is nice for
them to get new driver features by only upgrading their driver.

It is only partially baked so far, but I've thinking about some sort of
solution for issue (3) where the vendor who provides an extension GLX/EGL
function is also responsible for dispatching it to other vendors if
necessary.  Only the vendor implementations providing GLX/EGL extension
functions know how to interpret the function arguments in order to
dispatch to the right vendor.

I'll ponder that on my flight to Germany.

btw, I've put the proposal in source control here:

    https://github.com/aritger/linux-opengl-abi-proposal

so that it is easier to track updates.

Thanks,
- Andy




More information about the mesa-dev mailing list