https://bugs.freedesktop.org/show_bug.cgi?id=100073
--- Comment #15 from Timothy Arceri <t_arc...@yahoo.com.au> ---
(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).
>
> 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.
> 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.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
