RFC/WIP: Retracing without explicitly linking to libGL

[José Fonseca]

On Mon, Dec 5, 2011 at 10:12 AM, Alexandros Frantzis
<alexandros.frantzis at linaro.org> wrote:
> On Sat, Dec 03, 2011 at 10:29:37AM +0000, José Fonseca wrote:
>> On Fri, Dec 2, 2011 at 3:45 PM, Alexandros Frantzis
>> <alexandros.frantzis at linaro.org> wrote:
>> > On Fri, Dec 02, 2011 at 08:06:26AM +0000, José Fonseca wrote:
>> >> 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.
>> >>
>> >> Let me know if it works ok.
>> >>
>> >> Jose
>> >
>> > Hi Jose,
>> >
>> > I have pushed some fixes/improvements at:
>> >
>> > http://git.linaro.org/gitweb?p=people/afrantzis/apitrace.git;a=shortlog;h=refs/heads/glws-egl-xlib-fixes
>> >
>> > This branch is based on 'glproc-cleanup', although I am not sure if all
>> > the changes belong there conceptually. Here is a summary:
>> >
>> > 1. Use libGLESv2.so.2 as the OpenGL ES 2.0 library SONAME.
>> > 2. Cast native types to EGL types when calling EGL functions.
>> >
>> >  These are straightforward.
>>
>> I've applied these two and merged into master.
>>
>> > 3. Add 'profile' parameter to glws::createVisual().
>> > 4. Try to find the best matching EGL visual according to the profile.
>> > 5. Recreate the EGL visual to increase chances that it supports the requested api.
>> >
>> >  The existing mechanism for the selection of visuals could produce
>> >  strange results in some cases. For example, on systems that support
>> >  only ES1 and ES2, an ES1 visual was _always_ selected if there were
>> >  no ES1|ES2 visuals, even if we actually needed an ES2 visual.
>> >
>> >  By making the glws::createVisual() function aware of the requested
>> >  profile, we can provide better matching visuals.
>>
>> Finding a better visual sounds good.
>>
>> But the current way of recreating the visuals introduces dangling
>> pointers on multiple contexts, as previous context/drawables wll be
>> pointing to a non-existing visual structure. I see two solutions:
>> 1) delay creating the global glws::Visual until one is needed
>> 2) reference count glws::Visual
>
> Another idea is to create and store 3 visuals (i.e. make
> glretrace::visual an array of Visual *), one for each Profile. When a
> visual is needed, try to guess the best one to use based on the
> available (limited) information. Still a half-measure compared to what
> you are describing below, but I think it's clean and certainly more
> flexible than what we have now.
>
> I have uploaded a prototype of this approach here:
>
> http://git.linaro.org/gitweb?p=people/afrantzis/apitrace.git;a=shortlog;h=refs/heads/retrace-per-profile-visuals

Finally pushed after some tweaks.

>> Note that the current global visual is hack -- my plan was always to
>> recreate visuals that match what the application used --, but never
>> had time to do any better.
>
> I guess that for this to work, extra information about the used configs
> (attributes etc) needs to be logged at tracing time. Does the
> tracer/tracing format have support for something like this?

I don't think so -- all the information about the configs should be in
the call history, in the parameters passed/received by the
WGL/GLX/EGL/CGL APIs.

Jose