<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:oiaohm@gmail.com" title="oiaohm@gmail.com">oiaohm@gmail.com</a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - 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>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>WONTFIX
</td>
<td>FIXED
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - 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#c33">Comment # 33</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - 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 <span class="vcard"><a class="email" href="mailto:oiaohm@gmail.com" title="oiaohm@gmail.com">oiaohm@gmail.com</a>
</span></b>
<pre>(In reply to Timothy Arceri from <a href="show_bug.cgi?id=100073#c32">comment #32</a>)
<span class="quote">> As has been stated multiple times 32bit, 64bit, x32, arm, x86 etc are all
> mean nothing in regards to the resulting shader cache entries, you should be
> able to share them across platforms if not then there is a bug.
>
> The only reason for the 32, ipl-32 and 64 folders was to help keep different
> Mesa versions for 32 vs 64 from causing the cache to be deleted.
>
> After discussions about another issue it's been decided to move all cache
> entries to a single cache dir and instead use the timestamp (in future maybe
> build-id hash) and gpu id as part of the cache entries sha input.</span >
I would suggest keeping build-id and gpu-id outside the sha value. Hash
collisions are rare but you can fairly much bet someone will do it at some
point not point salting the hash and altering risk. Also if have removed a
particular version of mesa from the system for good being able to flush all
cache entries that no longer apply by deleting all the cache entries with that
build-id. If you have removed a particular gpu for good same with the gpu-id.
Embedded in the hash will make cleaning cache harder.
Basically make mesa form triplets [build-id]-[gpu-id]-[hash] for platform
sensitive [build-id]-[gpu-id]-[arch]-[hash]
That should cover most cases. Also having the file-name triplet it could be
possible to have a update tool to update from one build-id to new build-id
cache entries if someone every wants to attempt that.
It is important that everyone learns don't trust timestamps to be unique the
world no longer works that way.
So this fix my worry by completely doing away with split. Seeing a split I
was thinking some form of shader uniqueness to arch or it was just masking over
a bug that need fixing it turned out to be the case. So thank you for your
time.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>