Jose Fonseca <jfons...@vmware.com> writes: > On 14/09/16 11:03, Eric Anholt wrote: >> I've applied Dylan's comments to the RFC series, and I've pushed a >> starting trace-db with reference images for my i965 and vc4: >> >> https://github.com/anholt/trace-db > > Eric, > > This is great initiative IMO. > > > One suggestion: you can get much smaller traces by repacking traces into > the Brotli format. > > For example: > > $ wget > https://github.com/anholt/trace-db/raw/master/traces/humus/HDR.trace > $ apitrace repack --brotli HDR.trace HDR.brotli.trace > $ du -sh HDR*.trace > 4.5M HDR.brotli.trace > 7.2M HDR.trace > > > I introduced Brotli format precisely because some legacy OpenGL apps > that don't use VBOs yield a mind boggling traces. But with effective > compression it's managable again. For some of these we see traces 10x > smaller going from snappy to brotli. > > The decompression speed is a bit slower in terms of CPU, but when > factored disk access time, it's a net win too. > > > The only thing to keep in mind is that qapitrace will not work with > brotli files because they are not seekable. But it's just a matter of > repacking again to snappy (the repack operation is lossless.)
Great! I don't think it makes sense to repack the existing ones (they're in the git history already, and not small enough to justify telling people to git clone --depth yet), but this will definitely extend the lifetime of the github repo. That's a real shame about qapitrace, though. Is there no seeking at all, even if qapitrace did an initial scan to note some points it would want to go back to?
Description: PGP signature
_______________________________________________ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit