José Fonseca

> other good option would be if Microsoft documented the vsglog file format so ability to be parsed could be achieved.. I don't see much point in actually parsing vslog....

The ordinal import here worked just fine here when I tried. I wonder if the problem here is that you're building 32 bits apitrace, while trying to trace a 64bits...

For reference of those interested there's now - https://github.com/apitrace/apitrace/pull/701 - https://github.com/Joshua-Ashton/apitrace/tree/d3d12 (see also https://blog.froggi.es/d3d12-apitrace-capture-and-replay/ ) Hopefully we'll D3D12 support merged in the near future.

> Any plans for vulkan support ? No, not from my part. My recommendation would be to use [vktrace](https://vulkan.lunarg.com/doc/view/latest/linux/trace_tools.html) or RenderDoc

The problem I hit when replaying the trace with debug build of d3dretrace, is that the application is making two locks of the same vertex buffer at the same time:...

I won't have time to implement, but these sound reasonable enhancements. Particularly `glGetTexLevelParameter` and the _do-the-readback-with-no-information-and-hope-it-works_ fallback. I agree any incremental improvement here is progress.

> Making this work may be as simple as keeping around in memory that last frame's worth of Call objects and just sequencing through them repeatedly. That will still have...

> I am in favor of a raw format for ease of indexing and reverse traversal for trim dependency analysis. @casseveritt reverse traversal for trim dependency analysis is a bad...

zlib was slow, even with Z_BEST_SPEED, hence @zackr integrated snappy. I don't know about Z_NO_COMPRESSION.

> 2) retrace it from memory would work. But it is going to use obscene amount of memory on larger traces. I'd like into experiment with singleton values -- i.e.,...