<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Shader Disk Cache 32/64 bit detection has a flaw. Missed existence of x32 ABI" href="https://bugs.freedesktop.org/show_bug.cgi?id=100073#c19">Comment # 19</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Shader Disk Cache 32/64 bit detection has a flaw. Missed existence of x32 ABI" href="https://bugs.freedesktop.org/show_bug.cgi?id=100073">bug 100073</a> from <a class="email" href="mailto:t_arceri@yahoo.com.au" title="Timothy Arceri <t_arceri@yahoo.com.au>"> Timothy Arceri</a> <pre>(In reply to oiaohm from <a href="show_bug.cgi?id=100073#c17">comment #17</a>) > (In reply to Timothy Arceri from <a href="show_bug.cgi?id=100073#c15">comment #15</a>) > > (In reply to oiaohm from <a href="show_bug.cgi?id=100073#c12">comment #12</a>) > > > (In reply to Timothy Arceri from <a href="show_bug.cgi?id=100073#c11">comment #11</a>) > > > > (In reply to oiaohm from <a href="show_bug.cgi?id=100073#c9">comment #9</a>) > > > > > Jan Vesely > > > > > 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. > > > > > > > > > > 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. > > > > > > > > > > <a href="https://reproducible-builds.org/docs/timestamps/">https://reproducible-builds.org/docs/timestamps/</a> > > > > > > > > > > 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 > > > > > > <a href="https://en.wikipedia.org/wiki/X32_ABI">https://en.wikipedia.org/wiki/X32_ABI</a> > > > 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. > > > <a href="http://stackoverflow.com/questions/34011718/is-ilp32-and-i386-a-valid">http://stackoverflow.com/questions/34011718/is-ilp32-and-i386-a-valid</a>- > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>