On 2017-11-09 19:40:40, Jordan Justen wrote: > On 2017-11-09 08:07:57, Jose Fonseca wrote: > > On 09/11/17 13:19, Emil Velikov wrote: > > > On 9 November 2017 at 06:42, Jordan Justen <jordan.l.jus...@intel.com> > > > wrote: > > >> Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com> > > > Currently zlib is a dependency for !WIndows platforms. > > > With this patch we add it to the Windows builds. > > > > > > Brian, Jose any ideas how we can get zlib on Windows? > > > > > > Thanks > > > Emil > > > > > > > Thanks for the heads up Emil! > > > > The most effective way to get zlib on Windows would be to bundle the > > source code in mesa/src/zlib. > > > > But it would be much simpler we did not add zlib as a required dependency. > > > > Could we use some other checksum/hash? > > > > Or instead of bundling the whole zlib, we could just bundle crc > > implementation. I'm sure there are many BDS/MIT licensed out there. > > I've used some in apitrace -- > > https://github.com/apitrace/apitrace/tree/master/thirdparty/crc32c > > We have bundled crc32 already. > > I compress the program, but it is optional, and compression is not > used if it actually doesn't produce a smaller result. I'll update the > series such that if zlib is not available, then we'll always produce > an uncompressed result.
Well, this plan pretty much ran off the tracks when I tried to make the shader cache binary optionally compressed as well. :) I guess I'll just not build this on windows like disk_cache. Or ... as Tim suggested on irc, I could just not compress it. The data is very compressible, so should we just trust that the application probably will try to compress the returned binary? For reference, I don't think anv bothers to compress the pipeline binary... -Jordan _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
