<div class="gmail_quote">On Thu, Dec 1, 2011 at 11:43 PM, Alexandros Frantzis <span dir="ltr"><<a href="mailto:alexandros.frantzis@linaro.org">alexandros.frantzis@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Dec 01, 2011 at 09:42:03PM +0000, José Fonseca wrote:<br>
> Hi Alexandros,<br>
><br>
> Looks good overall.<br>
><br>
> But there's one detail I'd prefer see done differently: it's better not to<br>
> introduce this reverse/cyclic dependency from glproc to glws. glproc should<br>
> be self-sufficient, and the code organized in the following layers:<br>
><br>
> (e)glimports // type definitions<br>
> |<br>
> V<br>
> glproc // dynamic binding of the entrypoints<br>
> |<br>
> V<br>
> glws // window system abstraction<br>
> |<br>
> V<br>
> (e)glretrace // actual application<br>
><br>
> The <a href="https://github.com/apitrace/apitrace/tree/glproc-cleanup" target="_blank">https://github.com/apitrace/apitrace/tree/glproc-cleanup</a> takes some of<br>
> your changes but obverses the above scheme. There's more stuff I wanna do<br>
> in glproc, but it's a good step. I've already tested it on<br>
> Linux/MacOSX/Windows, so if it doesn't regress Android for you I'll merge<br>
> it.<br>
<br>
</div>The main problem I see, is that __libegl_sym() opens only libEGL.so, so<br>
it can only access egl (not gl) symbols through dlsym(). On Mesa, the<br>
core gl* symbols are actually returned by the call to eglGetProcAddress(),<br>
but this behavior goes against the EGL spec: "eglGetProcAddress may not<br>
be queried for core (non-extension) functions in EGL or client APIs",<br>
and is not supported by strictly conforming drivers. For example, this<br>
fails with the PVR driver for the embedded SGX cores.<br></blockquote><div><br></div><div>hmm.. this is very confusing. I'll need to read more about EGL ABI.</div><div><br></div><div>So, in summary:</div><div>- dlsym(dlopen("libGL.so"), XXX) for core GL functions</div>
<div>- dlsym(dlopen("libGLESv1_CM.so"), XXX) for for GLES 1 core functions</div><div><div>- dlsym(dlopen("libGLESv2.so"), XXX) for for GLES 2 core functions</div></div><div><div>- eglGetProcAddress(XXX) for extensions (any API)</div>
</div><div><br></div><div>What about the functions which are common to all? e.g., glEnable? can we pick any of the libGL(ES)*.so libraries or do we need to ensure that they are only used in the right context?</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Consequently, we need a mechanism, like the one in the<br>
'retrace-no-link-gl-wip' patchset, to select and dlopen() the correct gl<br>
library depending on the current context. Of course, in this case we<br>
don't have access to saved glws state, but we can easily figure out the<br>
current API and version using EGL functions.</blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">If you'd like, I can work on a patch for this. We just need to make sure<br>
we don't both start working on it :)<br></blockquote><div><br></div><div>I'll be offline soon, so feel free to work on a follow on patch.</div><div><br></div><div>Jose</div></div><br>