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