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?
signature.asc
Description: PGP signature
_______________________________________________ Piglit mailing list Piglit@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/piglit
