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 <b...@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_arc...@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
<tarc...@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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
