[Mesa-dev] [PATCH] texobj: add verbose api trace messages to several routines
jfonseca at vmware.com
Sun Jun 16 10:18:02 PDT 2013
On Sat, Jun 15, 2013 at 8:05 PM, Carl Worth <cworth at cworth.org> wrote:
> José Fonseca <jfonseca at vmware.com> writes:
> > FYI, with
> > apitrace no longer crashes with Steam overlay.
> Thanks, José! This will be quite handy. And it's a fix I'd been hoping
> to make for apitrace, but hadn't gotten around to.
> It's also nice to see that you got __libc_dlsym working. When I wrote a
> similar dlsym wrapper for fips I think I tried that but didn't get it to
> work for some reason. (I ended up with something that feels more fragile
> by calling dlvsym to find "dlsym".) So I'll revisit this with the
> apitrace code in mind.
> > But the overlay's rendering is not shown/captured when when apitrace
> > uses LD_PRELOAD.
> Do you know why this is?
No, I don't have a clear understanding.
There are many ways where multiple LD_PRELOAD objects can interfere with
each other (beyond the problem found). If all preload .so did
dlsym(RTLD_NEXT, "foo") then they would probably nest safely. But given we
need to intercept dlsym and/or dlpen, plus functions like glxGetProcAddress.
Even if they nested properly, depending on the ordering of apitrace vs
overlay one might get the overlay working but not actually recorded on file.
But I get the feeling that something is triggering the Steam overlay to not
activate at all.
> I'd definitely be interested in making apitrace work more transparently
Me too. But there are so many apps that only work well with
LD_LIBRARY_PATH, that make think that the best way forward is not to keep
adding hacks for LD_PRELOAD to work, but rather making apitrace seemingly
use LD_LIBRARY_PATH out of the box.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mesa-dev