----- Original Message -----
>
>
> On Mon, 4 Mar 2013, Carl Worth wrote:
>
> > I don't think it should be too hard to get this to work, (though it
> > may require a source change to the Steam overlay). I'll do some more
> > experiments tomorrow and see if I can't make a concrete recommendation
> > to be able to give to Valve as a bug report.
> >
> > And, obviously, if there's something we can do to make apitrace more
> > robust here, I'll submit that change as well.
>
> I faced a similar issue in my lightweight OpenGL offloading via GLX forking
> project, primus [1], and I'm successfully using the following approach:
>
> 1) The interposition is based on LD_LIBRARY_PATH augmentation, LD_PRELOAD is
> not employed. Pro: no ugly tricks with dlopen/dlsym interposition. Contra:
> the interposer needs to know the path to the "real" OpenGL library. For
> APITrace, /usr/$LIB/libGL.so.1 will usually be a working default choice (NB:
> $LIB is a special token expanded by the dynamic loader, not the shell).
$LIB is a neat idea. But does it work on debian/ubuntu systems, where
mesa/NVIDIA libGL.so are put in different paths , which are then chosen via
/etc/ld.so.conf*?
Another thing I was considering trying is to call dlinfo(RTLD_DI_SERINFO) to
extract the search path, and then iterate over it, skipping the directory where
apitrace wrapper is.
But of course, "apitrace trace" could easily just do dlopen("libGL.so.1") and
fill TRACE_LIBGL env var with it.
> 2) Specifically in order to work with the Steam overlay, the interposer
> *protects itself from dlsym interposition* by using
> real_dlsym = dlsym(dlopen("libdl.so.2"), "dlsym"). Similar protection
> against
> dlopen interposition would also make sense.
I see... Yes, if apitrace's dlopen() calls get intercepted by the overload then
that would explain the infinite recursion.
There is no guarantee that when we do
real_dlsym = dlsym(dlopen("libdl.so.2"), "dlsym")
that a fake_dlsym or a fake_dlopen doesn't return itself. But I suppose it
can't hurt.
> Hope that helps,
Yeah, thanks.
> Alexander
>
> [1] https://github.com/amonakov/primus
Very interesting project. It's a pity that all Linux GL implementers couldn't
agree on a shared libGL.so and some sort of GL DDI, as it would simplify the
deployment of features like GPU offloading.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
