[Mesa-dev] [Bug 100073] Shader Disk Cache 32/64 bit detection has a flaw. Missed existence of x32 ABI

[bugzilla-daemon at freedesktop.org]

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

--- Comment #19 from Timothy Arceri <t_arceri at yahoo.com.au> ---
(In reply to oiaohm from comment #17)
> (In reply to Timothy Arceri from comment #15)
> > (In reply to oiaohm from comment #12)
> > > (In reply to Timothy Arceri from comment #11)
> > > > (In reply to oiaohm from comment #9)
> > > > > Jan Vesely
> > > > > <b>If the pointer size is the same and the timestamp is the same, the cache
> > > > > will be reused, not deleted, and the problem does not exist.</b>
> > > > > 
> > > > > I have a little problem. I have x32 and i386.   So pointer size is the same
> > > > > timestamp and contents of cache should be different.   This will happen if I
> > > > > am running a reproducible build with frozen time.   This can also happen if
> > > > > you make to 64 library builds with frozen time because the two builds will
> > > > > have the same timestamps even if they are completely different versions of
> > > > > mesa incompatible disc cache requirements.
> > > > > 
> > > > > https://reproducible-builds.org/docs/timestamps/
> > > > > 
> > > > > The reason I provided this link is time is no longer trust-able as a unique
> > > > > value.  Do note the usage of libfaketime its really simple to forget you
> > > > > still have that loaded after doing a reproducible build so the clock is not
> > > > > in fact ticking forwards for anything you are doing you wake up when you
> > > > > finally do something that is dependant on the clock in fact ticking.   So
> > > > > you need to look at other sources to get unique value.
> > > > 
> > > > x32 should end up in the ilp-32 directory. That's what the __ILP32__ is
> > > > meant to do. Even if it didn't and the cache wasn't deleted because all your
> > > > arch builds had the same timestamp it still wouldn't matter because the
> > > > timestamp is used to identify the Mesa version not the arch, the arch
> > > > doesn't matter in terms of the cache it will work just fine. The only reason
> > > > for the different dirs is because we have no way of knowing if the different
> > > > timestamps are the same Mesa version
> > > 
> > > 1 if you are using timestamp it ID mesa version just use mesa version.
> > 
> > We can't, distros patch Mesa we can't depend on the version numbers being an
> > accurate representation of the source that was use to compile a Mesa
> > binaray. There is an option to do a sha of the binaries but that is a little
> > more complex for opengl than it is for vulkan (where it is currently used by
> > Intel).
> 
> Distribution will block using timestamp.  So timestamp cannot be used to
> perform task.

I'm pretty sure that's what Vulkan drivers were already doing in the previous
release. If distros are going to disable features I can't stop that.

> 
> Hashing to support your usage case might be the only way.

Happy for patches to implement this.

> > 
> > > 
> > > Next do read what x32 API is 
> > > 
> > > https://en.wikipedia.org/wiki/X32_ABI
> > > There is a different count in registers between i386 and x32.  So yes they
> > > both report as ilp-32
> > 
> > gcc only sets the __ILP32__ flag for x32 not i386. Clang may differ I'm not
> > sure, but it's not a major concern for me right now.
> > 
> http://stackoverflow.com/questions/34011718/is-ilp32-and-i386-a-valid-
> configuration
> Yes Clang sets __ILP32__ on i386 build modes.
> 
> __ILP32__ is a valid description for i386.   Should be presumed as being
> possible to be set in i386.
> 
> In fact gcc not having __ILP32__ set for i386 could be called a bug. 
> Depending on __ILP32__ to split i386 and x32 mode is depending on complier
> behaviour not specification defined behaviour.

We want to avoid hooks into the build system. If you have a better idea how to
do this than is currently done please submit a patch for review.

> 
> > > but if you are running a software rendering engine how
> > > the how the shader code has to be optimised is totally different to take
> > > advantage of x32 mode.
> > 
> > How about you go read about gpu architectures. Shader code is for the gpu,
> > x32
> > is for the cpu. There is no shader code optimisations to take advantage of
> > x32 mode.
> 
> In upstream currently there are none at the moment for software rendering
> you are right.  In prototype hack patches to get more performance out of
> software rendering in x32 mode there is.   As I said to take advantage of
> x32 mode it need to be different.  Not that upstream has it different now. 
> To make it possible for in future x32 patches to go upstream it need to be
> kept split at the cache.

There is no shader cache for software renderers so this, or any other issues to
do with caching for software renders in not a current concern. It would be more
likely that we would use the gpu_id as a way to distinguish between
implementations anyway.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170310/2688e18d/attachment.html>