[PATCH] Fix glFenceSync() retracing

[José Fonseca]

Ryan,

I see the problem, but unfortunately this change will break retracing
glFlushMappedBufferRange with a sub-range, and user memory pointers as
recorded by the virtual-address-regions branch (which tries to
reconstruct data in user arrays via mallocs and memcpys).

Glsync is a peculiar type, given it is both an opaque, but also an handle.

The long term solution is to make the trace format more expressive,
and to disambiguate pointers to opaque objects, from pointers to
opaque blobs (which can be referred partially, such as
glMapRange/glFlushMappedBufferRange).

But I'll think a bit more to see if there's any other easy workaround
we could do in short term.

Jose

On Mon, Jan 9, 2012 at 6:09 AM, Ryan C. Gordon <icculus at icculus.org> wrote:
>
> Calling glFenceSync(), part of GL_ARB_sync, triggers an assertion in
> glretrace, because it thinks the returned pointer should be part of a
> previously-known address range (it isn't; it's more of a handle than a
> pointer).
>
> Patch attached. This fixed the problem here, but I'm not sure of the full
> ramifications of the change.
>
> --ryan.
>
>
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/apitrace
>