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@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
