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

[Emil Velikov]

Hi all,

On 11 February 2017 at 02:44, Pierre-Loup A. Griffais
 wrote:

> 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 share your sentiment here - it is too much of a wishful thinking. To
build on top of that:

Afaics currently one cannot get the LLVM version at runtime, so in the
odd corner case you will get issues when mesa is linked against shared
LLVM.
The latter of which what most distros explicitly opting for.

> 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.
>
Considering the earlier comment and the case Kai mentioned (note that
PPA builders do the same/similar thing) using the build-id is won't be
that conservative of a solution ;-)

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Matt Turner]

On Tue, Feb 7, 2017 at 3:31 PM, Timothy Arceri  wrote:
> On Tue, 2017-02-07 at 23:58 +0100, Matt Turner wrote:
>> On Tue, Feb 7, 2017 at 4:42 AM, Timothy Arceri > > wrote:
>> > This series adds support for a GLSL IR level and TGSI (OpenGL/st)
>> > level caches.
>> >
>> > There are a few small bug fixes and a little bit of restructuring
>> > to the GLSL IR patches to make things work for Gallium drivers vs
>> > just i965 previously, but nothing too major.
>> >
>> > The biggest change is patch 35 which changes the mesa cache
>> > directory to be more structured allowing us to not fallback to
>> > recompiles at draw time if we realise a cache item was created
>> > with an old version of Mesa. Patch 36 also cleans up old cache
>> > files so we shouldn't get into a possition were we are constantly
>> > evicting cache items because its never cleaned out.
>> >
>> > Even with the new directory structure I've still left in the
>> > code that adds the Mesa version string to cache items because
>> > users can do things like override the OpenGL version which will
>> > change the output (in future we might want to just add this as
>> > part of the sha1 input).
>> >
>> > This series does not include the patch that adds cache support
>> > to the radeonsi backend, the main reason for this is that llvm
>> > currently doesn't allow the version to be queried at runtime
>> > (as far as I'm aware) although it seems like other are interested
>> > in this feature [1] so I will follow up on that.
>> >
>> > 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.

I just sent the code:

[PATCH 1/2] util: Add utility build-id code.
[PATCH 2/2] anv: Use build-id for pipeline cache UUID.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Michel Dänzer]

On 14/02/17 04:50 AM, Matt Arsenault wrote:
>> On Feb 6, 2017, at 19:42, Timothy Arceri > > wrote:
>>
>> This series does not include the patch that adds cache support
>> to the radeonsi backend, the main reason for this is that llvm
>> currently doesn't allow the version to be queried at runtime
>> (as far as I'm aware) although it seems like other are interested
>> in this feature [1] so I will follow up on that.
> 
> This should not be necessary. Old bitcode is supposed to be forward
> compatible and should be autoupgraded. You should not need to check that
> the runtime version matches.

This isn't enough for the shader cache, since LLVM code changes can
potentially cause different machine code to be generated even for
identical LLVM IR, e.g. a fix for a bug which caused incorrect machine
code to be generated.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Matt Arsenault]

> On Feb 6, 2017, at 19:42, Timothy Arceri  wrote:
> 
> This series does not include the patch that adds cache support
> to the radeonsi backend, the main reason for this is that llvm
> currently doesn't allow the version to be queried at runtime
> (as far as I'm aware) although it seems like other are interested
> in this feature [1] so I will follow up on that.

This should not be necessary. Old bitcode is supposed to be forward compatible 
and should be autoupgraded. You should not need to check that the runtime 
version matches. The sticking point for AMDGPU specifically is I do not want to 
guarantee compatibility for the legacy intrinsics still in use. They have 
various problems, and some of them make it difficult to support auto upgrading 
them. Going forward I would like to maintain compatibility with new properly 
defined intrinsics.

-Matt___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Pierre-Loup A. Griffais]

On 02/11/2017 08:47 AM, Andre Heider wrote:

On 02/11/2017 03:44 AM, Pierre-Loup A. Griffais wrote:

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:

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.


Maybe that's just me, but if this series allows 3rd parties to ship and
run code from untrusted sources, then I don't see how this is off-topic.

It's rather that sort of topic that should not be discussed offline.


One could argue that it would be a good idea for Mesa to check that the 
cache directory isn't writable by other users in the system, or that the 
cache files are owned by the same user as the process. That's probably 
the extent of the security aspect Mesa would have to worry about for 
that feature.




Regards,
Andre



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Andre Heider]

On 02/11/2017 03:44 AM, Pierre-Loup A. Griffais wrote:

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:

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.


Maybe that's just me, but if this series allows 3rd parties to ship and 
run code from untrusted sources, then I don't see how this is off-topic.


It's rather that sort of topic that should not be discussed offline.

Regards,
Andre

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Kai Wasserbäch]

Hey,
Pierre-Loup A. Griffais wrote on 11.02.2017 03:44:
> 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:
>>> [...]
>>>
 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.

that version string would need to include the SVN revision, right? Otherwise all
users of LLVM trunk would be screwed*, right? At the moment that kind of
information is most often found in the package version, not what llvm-config
reports (e.g. my llvm-config says 5.0.0-devel, while it would need to say at
least something like 5.0.0-devel~svn294745). As an example, have a look at the
Debian and Ubuntu packages at  (maintained by the Debian
Developer for the in-distribution packages). And what would need to be reported
if I carry a local patch (because I might be testing a solution to a bug)? Right
now I've applied  on top of LLVM
and  (see
) as well as a revert of
7b32ae4df5bc19c378598d6a950a6019fa64ece6 (see
) on top of Mesa. At least
the patches for bug 97988 affect the generated instructions/IR.

* Sort of depends on whether the goal here is to get rid of the GLSL-source
shaders and only ship the pre-compiled ones or if it's more of a "initial speed
bump" thing. Though I honestly can't see the former working unless you redefine
Linux support in Steam as "only with SteamOS".

> 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.

BuildIDs could be working (at least on Debian and derived distributions as well
as Fedora/Red Hat, I know the BuildIDs are added). But of course, minor changes
which might not affect the usability of the cache, would still change that ID,
so the miss chance should be pretty high – especially for people following LLVM
trunk and/or Mesa master.
At the end of the day I really don't see how Steam "pre-filling" the cache is a
good idea. At least for me it's just going to be dead data more often than not,
that has to be cleaned out on top of all the ancient libraries in the Steam
runtime, which usually prevent Steam from launching with up-to-date drivers. I'd
rather have Mesa fill it on-demand. (And yes, I know most users would stay with
their distribution's versions, but then you'll have subtle differences in
applied patches to consider and I rather not have the binary versions for all of
those in my cache. Sure BuildID solves the loading/matching, but not that you
might never be able to use the pre-loaded objects.)

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Pierre-Loup A. Griffais]

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  writes:


On Wed, Feb 8, 2017, at 11:25, Matt Turner wrote:

On Wed, Feb 8, 2017 at 12:31 AM, Timothy Arceri

wrote:

On Tue, 2017-02-07 at 23:58 +0100, Matt Turner wrote:

On Tue, Feb 7, 2017 at 4:42 AM, Timothy Arceri

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

[Nicolai Hähnle]

On 07.02.2017 04:42, Timothy Arceri wrote:

This series adds support for a GLSL IR level and TGSI (OpenGL/st)
level caches.

There are a few small bug fixes and a little bit of restructuring
to the GLSL IR patches to make things work for Gallium drivers vs
just i965 previously, but nothing too major.

The biggest change is patch 35 which changes the mesa cache
directory to be more structured allowing us to not fallback to
recompiles at draw time if we realise a cache item was created
with an old version of Mesa. Patch 36 also cleans up old cache
files so we shouldn't get into a possition were we are constantly
evicting cache items because its never cleaned out.

Even with the new directory structure I've still left in the
code that adds the Mesa version string to cache items because
users can do things like override the OpenGL version which will
change the output (in future we might want to just add this as
part of the sha1 input).

This series does not include the patch that adds cache support
to the radeonsi backend, the main reason for this is that llvm
currently doesn't allow the version to be queried at runtime
(as far as I'm aware) although it seems like other are interested
in this feature [1] so I will follow up on that.

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.

Without the radeonsi patch min fps still goes up around 4 fps in
the Shadow of Mordor benchmark (although the stalls are still
very noticeable).

I should also point out that this enables a tgsi level cache for
r600, but I haven't tested this myself and lack the hardware.

Also any other Gallium driver that uses TGSI should also be able
to enable support.

Please review.


Thank you for this!

I've tried to dig through the patches, and the first ~half looks pretty 
good. Towards the end I started having some questions around the whole 
cache_fallback thing, and there are some bits and pieces throughout.


I made some comments about the order of patches, but I don't think 
that's too important after all, as long as the cache as a whole is 
guarded by a big enable that's at the end of the series.


Cheers,
Nicolai






[1] https://groups.google.com/forum/#!topic/llvm-dev/xUg8fAKIKsA

___
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

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

[Nicolai Hähnle]

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  writes:


On Wed, Feb 8, 2017, at 11:25, Matt Turner wrote:

On Wed, Feb 8, 2017 at 12:31 AM, Timothy Arceri

wrote:

On Tue, 2017-02-07 at 23:58 +0100, Matt Turner wrote:

On Tue, Feb 7, 2017 at 4:42 AM, Timothy Arceri

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

[Timothy Arceri]

On 10/02/17 21:35, Nicolai Hähnle wrote:

On 08.02.2017 23:31, Eric Anholt wrote:

Bas Nieuwenhuizen  writes:


On Wed, Feb 8, 2017, at 11:25, Matt Turner wrote:
On Wed, Feb 8, 2017 at 12:31 AM, Timothy Arceri 


wrote:

On Tue, 2017-02-07 at 23:58 +0100, Matt Turner wrote:
On Tue, Feb 7, 2017 at 4:42 AM, Timothy Arceri 

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

[Nicolai Hähnle]

On 08.02.2017 23:31, Eric Anholt wrote:

Bas Nieuwenhuizen  writes:


On Wed, Feb 8, 2017, at 11:25, Matt Turner wrote:

On Wed, Feb 8, 2017 at 12:31 AM, Timothy Arceri 
wrote:

On Tue, 2017-02-07 at 23:58 +0100, Matt Turner wrote:

On Tue, Feb 7, 2017 at 4:42 AM, Timothy Arceri 

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

[Eric Anholt]

Bas Nieuwenhuizen  writes:

> On Wed, Feb 8, 2017, at 11:25, Matt Turner wrote:
>> On Wed, Feb 8, 2017 at 12:31 AM, Timothy Arceri 
>> wrote:
>> > On Tue, 2017-02-07 at 23:58 +0100, Matt Turner wrote:
>> >> On Tue, Feb 7, 2017 at 4:42 AM, Timothy Arceri > >> > wrote:
>> >> > This series adds support for a GLSL IR level and TGSI (OpenGL/st)
>> >> > level caches.
>> >> >
>> >> > There are a few small bug fixes and a little bit of restructuring
>> >> > to the GLSL IR patches to make things work for Gallium drivers vs
>> >> > just i965 previously, but nothing too major.
>> >> >
>> >> > The biggest change is patch 35 which changes the mesa cache
>> >> > directory to be more structured allowing us to not fallback to
>> >> > recompiles at draw time if we realise a cache item was created
>> >> > with an old version of Mesa. Patch 36 also cleans up old cache
>> >> > files so we shouldn't get into a possition were we are constantly
>> >> > evicting cache items because its never cleaned out.
>> >> >
>> >> > Even with the new directory structure I've still left in the
>> >> > code that adds the Mesa version string to cache items because
>> >> > users can do things like override the OpenGL version which will
>> >> > change the output (in future we might want to just add this as
>> >> > part of the sha1 input).
>> >> >
>> >> > This series does not include the patch that adds cache support
>> >> > to the radeonsi backend, the main reason for this is that llvm
>> >> > currently doesn't allow the version to be queried at runtime
>> >> > (as far as I'm aware) although it seems like other are interested
>> >> > in this feature [1] so I will follow up on that.
>> >> >
>> >> > 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.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Matt Turner]

On Wed, Feb 8, 2017 at 11:38 AM, Bas Nieuwenhuizen
 wrote:
> On Wed, Feb 8, 2017, at 11:25, Matt Turner wrote:
>> On Wed, Feb 8, 2017 at 12:31 AM, Timothy Arceri 
>> wrote:
>> > On Tue, 2017-02-07 at 23:58 +0100, Matt Turner wrote:
>> >> On Tue, Feb 7, 2017 at 4:42 AM, Timothy Arceri > >> > wrote:
>> >> > This series adds support for a GLSL IR level and TGSI (OpenGL/st)
>> >> > level caches.
>> >> >
>> >> > There are a few small bug fixes and a little bit of restructuring
>> >> > to the GLSL IR patches to make things work for Gallium drivers vs
>> >> > just i965 previously, but nothing too major.
>> >> >
>> >> > The biggest change is patch 35 which changes the mesa cache
>> >> > directory to be more structured allowing us to not fallback to
>> >> > recompiles at draw time if we realise a cache item was created
>> >> > with an old version of Mesa. Patch 36 also cleans up old cache
>> >> > files so we shouldn't get into a possition were we are constantly
>> >> > evicting cache items because its never cleaned out.
>> >> >
>> >> > Even with the new directory structure I've still left in the
>> >> > code that adds the Mesa version string to cache items because
>> >> > users can do things like override the OpenGL version which will
>> >> > change the output (in future we might want to just add this as
>> >> > part of the sha1 input).
>> >> >
>> >> > This series does not include the patch that adds cache support
>> >> > to the radeonsi backend, the main reason for this is that llvm
>> >> > currently doesn't allow the version to be queried at runtime
>> >> > (as far as I'm aware) although it seems like other are interested
>> >> > in this feature [1] so I will follow up on that.
>> >> >
>> >> > 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.

Isn't that a job for something like GL_ARB_get_program_binary, rather
than an automatic shader cache?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Bas Nieuwenhuizen]

On Wed, Feb 8, 2017, at 11:25, Matt Turner wrote:
> On Wed, Feb 8, 2017 at 12:31 AM, Timothy Arceri 
> wrote:
> > On Tue, 2017-02-07 at 23:58 +0100, Matt Turner wrote:
> >> On Tue, Feb 7, 2017 at 4:42 AM, Timothy Arceri  >> > wrote:
> >> > This series adds support for a GLSL IR level and TGSI (OpenGL/st)
> >> > level caches.
> >> >
> >> > There are a few small bug fixes and a little bit of restructuring
> >> > to the GLSL IR patches to make things work for Gallium drivers vs
> >> > just i965 previously, but nothing too major.
> >> >
> >> > The biggest change is patch 35 which changes the mesa cache
> >> > directory to be more structured allowing us to not fallback to
> >> > recompiles at draw time if we realise a cache item was created
> >> > with an old version of Mesa. Patch 36 also cleans up old cache
> >> > files so we shouldn't get into a possition were we are constantly
> >> > evicting cache items because its never cleaned out.
> >> >
> >> > Even with the new directory structure I've still left in the
> >> > code that adds the Mesa version string to cache items because
> >> > users can do things like override the OpenGL version which will
> >> > change the output (in future we might want to just add this as
> >> > part of the sha1 input).
> >> >
> >> > This series does not include the patch that adds cache support
> >> > to the radeonsi backend, the main reason for this is that llvm
> >> > currently doesn't allow the version to be queried at runtime
> >> > (as far as I'm aware) although it seems like other are interested
> >> > in this feature [1] so I will follow up on that.
> >> >
> >> > 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.

- Bas 
> ___
> 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

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

[Matt Turner]

On Wed, Feb 8, 2017 at 12:31 AM, Timothy Arceri  wrote:
> On Tue, 2017-02-07 at 23:58 +0100, Matt Turner wrote:
>> On Tue, Feb 7, 2017 at 4:42 AM, Timothy Arceri > > wrote:
>> > This series adds support for a GLSL IR level and TGSI (OpenGL/st)
>> > level caches.
>> >
>> > There are a few small bug fixes and a little bit of restructuring
>> > to the GLSL IR patches to make things work for Gallium drivers vs
>> > just i965 previously, but nothing too major.
>> >
>> > The biggest change is patch 35 which changes the mesa cache
>> > directory to be more structured allowing us to not fallback to
>> > recompiles at draw time if we realise a cache item was created
>> > with an old version of Mesa. Patch 36 also cleans up old cache
>> > files so we shouldn't get into a possition were we are constantly
>> > evicting cache items because its never cleaned out.
>> >
>> > Even with the new directory structure I've still left in the
>> > code that adds the Mesa version string to cache items because
>> > users can do things like override the OpenGL version which will
>> > change the output (in future we might want to just add this as
>> > part of the sha1 input).
>> >
>> > This series does not include the patch that adds cache support
>> > to the radeonsi backend, the main reason for this is that llvm
>> > currently doesn't allow the version to be queried at runtime
>> > (as far as I'm aware) although it seems like other are interested
>> > in this feature [1] so I will follow up on that.
>> >
>> > 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.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Timothy Arceri]

On Tue, 2017-02-07 at 23:58 +0100, Matt Turner wrote:
> On Tue, Feb 7, 2017 at 4:42 AM, Timothy Arceri  > wrote:
> > This series adds support for a GLSL IR level and TGSI (OpenGL/st)
> > level caches.
> > 
> > There are a few small bug fixes and a little bit of restructuring
> > to the GLSL IR patches to make things work for Gallium drivers vs
> > just i965 previously, but nothing too major.
> > 
> > The biggest change is patch 35 which changes the mesa cache
> > directory to be more structured allowing us to not fallback to
> > recompiles at draw time if we realise a cache item was created
> > with an old version of Mesa. Patch 36 also cleans up old cache
> > files so we shouldn't get into a possition were we are constantly
> > evicting cache items because its never cleaned out.
> > 
> > Even with the new directory structure I've still left in the
> > code that adds the Mesa version string to cache items because
> > users can do things like override the OpenGL version which will
> > change the output (in future we might want to just add this as
> > part of the sha1 input).
> > 
> > This series does not include the patch that adds cache support
> > to the radeonsi backend, the main reason for this is that llvm
> > currently doesn't allow the version to be queried at runtime
> > (as far as I'm aware) although it seems like other are interested
> > in this feature [1] so I will follow up on that.
> > 
> > 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.


> ___
> 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

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

[Matt Turner]

On Tue, Feb 7, 2017 at 4:42 AM, Timothy Arceri  wrote:
> This series adds support for a GLSL IR level and TGSI (OpenGL/st)
> level caches.
>
> There are a few small bug fixes and a little bit of restructuring
> to the GLSL IR patches to make things work for Gallium drivers vs
> just i965 previously, but nothing too major.
>
> The biggest change is patch 35 which changes the mesa cache
> directory to be more structured allowing us to not fallback to
> recompiles at draw time if we realise a cache item was created
> with an old version of Mesa. Patch 36 also cleans up old cache
> files so we shouldn't get into a possition were we are constantly
> evicting cache items because its never cleaned out.
>
> Even with the new directory structure I've still left in the
> code that adds the Mesa version string to cache items because
> users can do things like override the OpenGL version which will
> change the output (in future we might want to just add this as
> part of the sha1 input).
>
> This series does not include the patch that adds cache support
> to the radeonsi backend, the main reason for this is that llvm
> currently doesn't allow the version to be queried at runtime
> (as far as I'm aware) although it seems like other are interested
> in this feature [1] so I will follow up on that.
>
> 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.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Timothy Arceri]

On Tue, 7 Feb 2017 16:54:31 +0100
Marek Olšák  wrote:

> On Tue, Feb 7, 2017 at 4:42 AM, Timothy Arceri
>  wrote:
> > Without the radeonsi patch min fps still goes up around 4 fps in
> > the Shadow of Mordor benchmark (although the stalls are still
> > very noticeable).  
> 
> I don't fully understand this. Can you elaborate on that?
> 
> There are 4 tests that can be done:
> 1) no shader cache: run the benchmark with mesa/master once
> 2) radeonsi cache: run the benchmark with mesa/master for the second
> time in the same process
> 3) glsl-tgsi cache: run the benchmark with your branch once after the
> disk cache is ready
> 4) both caches: run the benchmark with your branch for the second time
> in the same process

Since this is a series testing on-disk cache all tests are done by
running the benchmark once then closing the game before the next run.

Running the game for the second time where tgsi shaders are loaded from
cache improves the min fps and improves the various stalls where
shaders are compiles during the benchmark but does not eliminate them.
Adding the radoensi cache makes the benchmark run smoothly.

> 
> Marek
> ___
> 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

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

[Marek Olšák]

On Tue, Feb 7, 2017 at 4:42 AM, Timothy Arceri  wrote:
> Without the radeonsi patch min fps still goes up around 4 fps in
> the Shadow of Mordor benchmark (although the stalls are still
> very noticeable).

I don't fully understand this. Can you elaborate on that?

There are 4 tests that can be done:
1) no shader cache: run the benchmark with mesa/master once
2) radeonsi cache: run the benchmark with mesa/master for the second
time in the same process
3) glsl-tgsi cache: run the benchmark with your branch once after the
disk cache is ready
4) both caches: run the benchmark with your branch for the second time
in the same process

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Timothy Arceri]

On Tue, 7 Feb 2017 15:50:28 +0900
Michel Dänzer  wrote:

> On 07/02/17 12:42 PM, Timothy Arceri wrote:
> > 
> > This series does not include the patch that adds cache support
> > to the radeonsi backend, the main reason for this is that llvm
> > currently doesn't allow the version to be queried at runtime
> > (as far as I'm aware) although it seems like other are interested
> > in this feature [1] so I will follow up on that.
> > 
> > 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'm not sure that's realistic. Consider e.g.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=99078
> 
> which is a regression in LLVM 3.9.1 caused by backporting a fix from
> trunk. Since there are no plans for an LLVM 3.9.2 release, distros
> have to revert the change in their 3.9.1 packages. Mesa can't tell the
> difference from the version number, but the generated code can be very
> different depending on whether the change in question is present or
> not.

I wonder how problematic that really is, it just means the bug will be
in the cached version and it won't get replaced. It looks like other
users of llvm might be looking to rely on the version number so maybe
distros will need to bump the version themselves if llvm won't do a
release, not sure what to do about this.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Michel Dänzer]

On 07/02/17 12:42 PM, Timothy Arceri wrote:
> 
> This series does not include the patch that adds cache support
> to the radeonsi backend, the main reason for this is that llvm
> currently doesn't allow the version to be queried at runtime
> (as far as I'm aware) although it seems like other are interested
> in this feature [1] so I will follow up on that.
> 
> 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'm not sure that's realistic. Consider e.g.

https://bugs.freedesktop.org/show_bug.cgi?id=99078

which is a regression in LLVM 3.9.1 caused by backporting a fix from
trunk. Since there are no plans for an LLVM 3.9.2 release, distros have
to revert the change in their 3.9.1 packages. Mesa can't tell the
difference from the version number, but the generated code can be very
different depending on whether the change in question is present or not.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Timothy Arceri]

This series adds support for a GLSL IR level and TGSI (OpenGL/st)
level caches.

There are a few small bug fixes and a little bit of restructuring
to the GLSL IR patches to make things work for Gallium drivers vs
just i965 previously, but nothing too major.

The biggest change is patch 35 which changes the mesa cache
directory to be more structured allowing us to not fallback to
recompiles at draw time if we realise a cache item was created
with an old version of Mesa. Patch 36 also cleans up old cache
files so we shouldn't get into a possition were we are constantly
evicting cache items because its never cleaned out.

Even with the new directory structure I've still left in the
code that adds the Mesa version string to cache items because
users can do things like override the OpenGL version which will
change the output (in future we might want to just add this as
part of the sha1 input).

This series does not include the patch that adds cache support
to the radeonsi backend, the main reason for this is that llvm
currently doesn't allow the version to be queried at runtime
(as far as I'm aware) although it seems like other are interested
in this feature [1] so I will follow up on that.

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.

Without the radeonsi patch min fps still goes up around 4 fps in
the Shadow of Mordor benchmark (although the stalls are still
very noticeable).

I should also point out that this enables a tgsi level cache for
r600, but I haven't tested this myself and lack the hardware.

Also any other Gallium driver that uses TGSI should also be able
to enable support.

Please review.

[1] https://groups.google.com/forum/#!topic/llvm-dev/xUg8fAKIKsA 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev