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

[Andy Ritger]

On Thu, Sep 13, 2012 at 11:55:06PM -0700, Kenneth Graunke wrote:
> On 09/12/2012 02:09 PM, 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.
> 
> Andy,
> 
> I haven't yet read through this completely, but everything I saw looks
> fantastic.  A bunch of us on the Intel team have been talking about
> separating out libGL into libGLX and libOpenGL for a few months now.
> Having it in libGL just doesn't make sense these days: it's completely
> reasonable to use GL + EGL, at which point GLX is useless, and having it
> in libGL makes it (near?) impossible to use GLX + GLES.
> 
> We've even talked about deprecating GLX entirely, and encouraging
> everyone to use EGL instead.  There's a lot of things about GLX that
> just painful to deal with, and little work is being done to it.  EGL is
> actively worked on and extended, cross platform, and from what I've seen
> a nicer API to work with.
> 
> I like that you're trying to solve the vendor-specific libGL problem as
> well.  Getting that right would definitely make life much easier both
> for packagers and ultimately normal users.
> 
> Thanks for taking the initiative here; both for starting the discussion
> and for writing up such a detailed (and spec-style!) proposal.

Great; thanks for the feedback, Ken.  It sounds like we're on the
same page.  We'll see how things go as we work through the details.

FWIW, I think there is still a place for GLX (if for nothing else
than compatibility with the rich history of existing applications).

But in any case, it makes sense to separate the entry points out into
separate libraries for the distinct APIs.

Thanks,
- Andy

> --Ken