On 11/11/17 01:37, Jordan Justen wrote:
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.
Sounds fine to me.
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...
I think that the landscape of OpenGL on Linux is substantially
different, but our experience on Windows land is that applications tend
to be developed against NVIDIA/AMD OpenGL drivers, and whatever is their
behavior, it tends up to be assumed as a de facto standard, even when no
such guarantee is given by the spec.
In other words, it usually pays off to avoid divergence relative to
binary blobs. That said, it probably doesn't make a big difference
either way.
Another thing to consider is that, if the application compresses
(instead of the OpenGL driver) then it might be able to exploit
redundancy _across_ multiple programs (e.g. by tarballing all together.)
Something that the OpenGL driver cannot do. And if the OpenGL driver
compresses the blobs, it will actually make it harder for apps to
exploit intra-shader redundancy. Of course, we don't know what apps
will or not do, so this is speculating. But perhaps by not compressing
we might be nudging towards the overall ideal behavior, of apps
compressing the whole program cache as a lump.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
