<div dir="ltr">On Thu, Apr 25, 2013 at 9:59 PM, Andy Ritger <span dir="ltr"><<a href="mailto:aritger@nvidia.com" target="_blank">aritger@nvidia.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Thu, Apr 25, 2013 at 05:34:11AM -0700, Ian Romanick wrote:<br>
> On 04/25/2013 11:12 AM, Andy Ritger wrote:<br>
> > Hi all,<br>
> ><br>
> > Last fall, I put together a proposal for an updated Linux OpenGL ABI<br>
> > specification:<br>
> ><br>
> > <a href="https://github.com/aritger/linux-opengl-abi-proposal/blob/master/linux-opengl-abi-proposal.txt" target="_blank">https://github.com/aritger/linux-opengl-abi-proposal/blob/master/linux-opengl-abi-proposal.txt</a><br>
> ><br>
> > but then got distracted. I'd like to try to resurrect the discussion.<br>
> ><br>
> > From the earlier email thread and some discussion at XDC2012, it sounded<br>
> > like people thought the general ideas were reasonable. However, there are<br>
> > a variety of details to work through, called out in the issues section.<br>
> ><br>
> > To get things moving, I thought I, and a few others from NVIDIA, would<br>
> > try to prototype some of the vendor-neutral API Libraries described in the<br>
> > document. That might give us all something more concrete to play with.<br>
> ><br>
> > Feedback on anything in the full proposal welcome, but here are a few<br>
> > more specific questions:<br>
> ><br>
> > * For a prototype, what is a reasonable version of OpenGL to provide<br>
> > in libOpenGL.so.1? There are a variety of options enumerated in the<br>
> > full proposal for how to handle sets of entry points, but my sense is<br>
> > that the simplest solution is for libOpenGL.so.1 to provide a reasonable<br>
> > base version of OpenGL, and then all entry points for extensions and<br>
> > later OpenGL versions to be accessed through {egl,glX}GetProcAddress.<br>
><br>
> If it's just the availability of the entry points (w/o using<br>
> GetProcAddress), I don't see any reason to include less than 4.3 + every<br>
> ARB extension.<br>
<br>
</div>Thanks, Ian.<br>
<br>
Yes, this is just about the availability of entry points as symbols in<br>
the DSO. It sounds good to me to cast a wide net and export a large<br>
set of symbols.<br>
<br>
Do you have a vision for any upgrade of that set of symbols? My hope<br>
is that libOpenGL.so.1 will be maintained/distributed independently of<br>
any specific vendor's OpenGL implementation. Maybe in an ideal world<br>
it would get revved everytime Khronos releases a new OpenGL version,<br>
or a new ARB extension is ratified. But, then we need to worry about<br>
(a) someone keeping it up to date, and (b) handling the version number<br>
in libOpenGL.so's SONAME, so that an application can express which<br>
symbols it expects the DSO to provide.<br>
<br>
Given tools like GLEW, it may be easier for applications to just assume<br>
whatever fixed list we lock down initially for the new ABI, and then<br>
use GetProcAddress for everything else.<br>
<br>
I don't think we need to decide, yet, how frequently to update the<br>
exported symbol list from libOpenGL.so. But, it is probably worthing<br>
thinking about, if we define in the ABI that libOpenGL.so will export<br>
symbols for 4.3 + every ARB extension, as of April 25, 2013.<br>
<div><br>
> > * From some initial reading, Mesa's glapi (src/mapi/glapi/) looks useful<br>
> > for the basis of libOpenGL.so.1's dispatching. Would it be reasonable<br>
> > to use glapi in the prototype libOpenGL.so.1?<br>
><br>
> Yes.<br>
><br>
> > * The vendor-neutral libEGL.so.1 is intended to be a thin layer that<br>
> > would dispatch to the appropriate vendor. It looks like the frontend of<br>
> > Mesa's EGL implementation would be a good basis for the vendor-neutral<br>
> > libEGL.so.1. Would it be reasonable to use that for the prototype?<br>
><br>
> Yes. There is already mechanism to control which backend gets<br>
> dispatched within libEGL.so. It shouldn't be too hard to make it<br>
> discover additional .so files containing additional backends. Kristian<br>
> may have some ideas about how to do that.<br>
<br>
</div>Sounds good.<br></blockquote><div><br></div><div>The libEGL.so code in Mesa might not be exactly what you are looking for,</div><div style>the current dispatching is more like mesas internal driver dispatching then</div>
<div style>libGL.so straight up dispatching, as it validates some of the inputs, it also</div><div style>assumes a bit about the layout of certain structs and as such requires you</div><div style>write the driver against the is not opaque that interface is not ABI stable</div>
<div style>either. So think you will have to write the dispatching part from scratch to</div><div style>make it more just directly dispatch into the driver like libGL does.</div><div><br></div><div style>You can probably reuse some of the per thread state code from there tho</div>
<div style>since that needs to be in the libEGL implementation. I'm also uncertain</div><div style>about the loader code but it might be worth a look.</div><div style><br></div><div style>Cheers, Jakob.</div></div></div>
</div>