<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#c17">Comment # 17</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:oiaohm@gmail.com" title="oiaohm@gmail.com">oiaohm@gmail.com</a> <pre>(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. Hashing to support your usage case might be the only way. > > > > > 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-configuration">http://stackoverflow.com/questions/34011718/is-ilp32-and-i386-a-valid-configuration</a> 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. > > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>