[Mesa-dev] GLSL IR & TGSI on-disk shader cache

Sat Feb 11 02:44:43 UTC 2017

On 02/10/2017 04:01 AM, Nicolai Hähnle wrote:
> On 10.02.2017 12:46, Timothy Arceri wrote:
>>
>>
>> On 10/02/17 21:35, Nicolai Hähnle wrote:
>>> On 08.02.2017 23:31, Eric Anholt wrote:
>>>> Bas Nieuwenhuizen <bas at basnieuwenhuizen.nl> writes:
>>>>
>>>>> On Wed, Feb 8, 2017, at 11:25, Matt Turner wrote:
>>>>>> On Wed, Feb 8, 2017 at 12:31 AM, Timothy Arceri
>>>>>> <t_arceri at yahoo.com.au>
>>>>>> wrote:
>>>>>>> On Tue, 2017-02-07 at 23:58 +0100, Matt Turner wrote:
>>>>>>>> On Tue, Feb 7, 2017 at 4:42 AM, Timothy Arceri
>>>>>>>> <tarceri at itsqueeze.com
>>>>>>>>> wrote:
>>>>>>>>> The reason we don't just use the build time like radv is that we
>>>>>>>>> will want something consistent accross distros to enable
>>>>>>>>> distribution of precompiled shaders.
>>>>>>>>
>>>>>>>> I think I have a solution for this. I am traveling until next week,
>>>>>>>> but I will send it as soon as I can.
>>>>>>>
>>>>>>> Are you able to provide a hint as to what you are suggesting? I've
>>>>>>> just
>>>>>>> pinged the llvm about creating the api to query the version.
>>>>>>> Would be
>>>>>>> interested to know if your idea will make the unnecessary.
>>>>>>
>>>>>> Yes, (1) build with GNU ld's --build-id=sha1 flag, which embeds the
>>>>>> sha1 of the object into a special .note.gnu.build-id ELF note
>>>>>> section;
>>>>>> (2) read that section using dl_iterate_phdr() and a little bit of
>>>>>> parsing; (3) use sha1 plus perhaps other information to uniquely
>>>>>> identify the runtime configuration.
>>>>>>
>>>>>> I've written an example of how to do it here:
>>>>>> http://git.mattst88.com/build-id/
>>>>>>
>>>>>> That should definitely be better than the alternatives I've heard
>>>>>> proposed (mtime of the .so, manually hashing the source directory,
>>>>>> ...). I'm happy to implement this next week, or you can feel free to
>>>>>> give it a shot.
>>>>>
>>>>> Yeah,also  just figured that out during the week. The fundamental
>>>>> issue
>>>>> here is that the SHA1 might come out different due to compiler
>>>>> differences between distros, even if they are compiling exactly the
>>>>> same
>>>>> version. This increases the number of versions of the cache that
>>>>> have to
>>>>> be distributed if the application would like to distribute precompiled
>>>>> caches.
>>>>
>>>> I think that trying to apply precompiled binaries from one build of
>>>> Mesa+LLVM to different different builds of Mesa+LLVM is going to cause
>>>> us endless pain and Mesa shouldn't allow that.
>>>
>>> I agree.
>>>
>>> The people who want to distribute precompiled binaries will have to
>>> set up infrastructure where they do the precompilation across all the
>>> distro/build combinations that they want to support.
>>
>> I believe the plan is to also have them collected directly from users.
>
> Oh $deity, please no. That's a security nightmare waiting to happen.

Debatable, but off-topic either way; happy to chat about it offline.

>>> It's not even clear to me how they intend to load those precompiled
>>> binaries into the system. Is e.g. Steam just going to write into
>>> Mesa's cache directory? We can't really stop them if they really
>>> wanted to do that, but that seems like a pain.
>>
>> I believe that is the plan yes, same goes for the binary drivers.
>>
>>>
>>> I agree with Matt that this is precisely what
>>> GL_ARB_get_program_binary was designed for.
>>>
>>> If people are worried about the download sizes caused by the many
>>> build combinations, they should look into either
>>>
>>> (a) compression for that purpose, or
>> I will likely look into this once we land the initial cache. Currently
>> there is no real information on how large this repository will grow to,
>> so its more of a thought that a concern at this point.
>>
>> I don't know all the details of the planned system but hopefully this
>> helps give a bit of a picture into how it could work.
>
> Cool, thanks.

ARB_get_program_binary is not useful for collection/redistribution.

It seems like regardless of any external participant to the system, 
being robust against LLVM differences is something the cache needs to solve.

Ideally LLVM could expose a version string/number that's granular 
enough, and distros/users could be trusted to properly amend that 
version string if they make functional changes to something that can 
affect shader compilation, but maybe that's wishful thinking.

I'm not so sure that a build-id is a silver bullet here either, but if 
you can rely on its existence because it's written into the binary by a 
part of the build system that no distro will ever mess with, it seems 
like it would work. It would be more conservative than strictly needed, 
but that isn't a major issue in the short term. It would at least allow 
us to get compelling data showing whether moving to a less granular 
cache key would allow us to serve significantly more users.

Thanks,
  - Pierre-Loup

>
> Nicolai
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev