<br><br><div class="gmail_quote">On Fri, Dec 2, 2011 at 4:35 AM, Chia-I Wu <span dir="ltr"><<a href="mailto:olvaffe@gmail.com">olvaffe@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="HOEnZb"><div class="h5">On Fri, Dec 2, 2011 at 8:13 AM, José Fonseca <<a href="mailto:jose.r.fonseca@gmail.com">jose.r.fonseca@gmail.com</a>> wrote:<br>
> On Thu, Dec 1, 2011 at 11:43 PM, Alexandros Frantzis<br>
> <<a href="mailto:alexandros.frantzis@linaro.org">alexandros.frantzis@linaro.org</a>> wrote:<br>
>><br>
>> 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<br>
>> > to<br>
>> > introduce this reverse/cyclic dependency from glproc to glws. glproc<br>
>> > 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<br>
>> > of<br>
>> > your changes but obverses the above scheme. There's more stuff I wanna<br>
>> > 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<br>
>> > merge<br>
>> > it.<br>
>><br>
>> 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>
><br>
><br>
> hmm.. this is very confusing. I'll need to read more about EGL ABI.<br>
> So, in summary:<br>
> - dlsym(dlopen("libGL.so"), XXX) for core GL functions<br>
> - dlsym(dlopen("libGLESv1_CM.so"), XXX) for for GLES 1 core functions<br>
> - dlsym(dlopen("libGLESv2.so"), XXX) for for GLES 2 core functions<br>
> - eglGetProcAddress(XXX) for extensions (any API)<br>
</div></div>EGL/GLES says nothing about ABI, sadly. EGL spec only states that:<br>
<div class="im"><br>
eglGetProcAddress may not be queried for core (non-extension) functions in<br>
</div> EGL or client APIs.<br>
<br>
Yet, it does not define the corresponding versions of client APIs..<br>
Worse, there are also implementations that eglGetProcAddress is<br>
somewhat broken. There are also systems that dlopen cannot be<br>
overridden.<br>
<br>
Currently, __libegl_sym tries dlsym(RTLD_NEXT, ...) and, if that<br>
fails, then eglGetProcAddress. It obviously will not work for many<br>
cases, but it may not be easy to find a way to work reliably across<br>
OSes/implementations.<br>
<div class="im">> What about the functions which are common to all? e.g., glEnable? can we<br>
> pick any of the libGL(ES)*.so libraries or do we need to ensure that they<br>
> are only used in the right context?<br>
</div>Nothing is said about this case. Implementations I've seen allow any<br>
of the libraries to be picked. Function pointers returned by<br>
eglGetProcAddress are required to work with any context. But then,<br>
glEnable cannot be queried with eglGetProcAddress...<br>
<div class="im HOEnZb">><br>
>><br>
>> 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.<br>
><br>
><br>
>> 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>
><br>
><br>
> I'll be offline soon, so feel free to work on a follow on patch.<br>
><br>
> Jose<br>
><br>
><br>
</div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> apitrace mailing list<br>
> <a href="mailto:apitrace@lists.freedesktop.org">apitrace@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/apitrace" target="_blank">http://lists.freedesktop.org/mailman/listinfo/apitrace</a><br>
><br><br></div></div></blockquote><div><br></div><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color: rgba(255, 255, 255, 0.917969); "><div class="gmail_quote">
<div>I've pushed a follow on patch that tries to do the right thing, namelly dlopen the right libGL/GLES*.so on demand. I also tried to document this better.</div><div><br></div><div>Let me know if it works ok.</div><div>
</div></div></span><div><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color: rgba(255, 255, 255, 0.917969); ">Jose</span> </div></div>