[Mesa-dev] [PATCH 16/17] util: Add Mesa ARB_get_program_binary helper functions

[Jose Fonseca]

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.justen at intel.com> wrote:
>>>>> Signed-off-by: Jordan Justen <jordan.l.justen at 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