<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#c12">Comment # 12</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#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. 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 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.</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>