[Mesa-dev] [Bug 100073] Shader Disk Cache 32/64 bit detection has a flaw. Missed existence of x32 ABI

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=100073

--- Comment #29 from oiaohm at gmail.com ---
(In reply to Tobias Droste from comment #27)
> They are build from the same source code version so it's perfectly fine for
> them to have the same timestamp.
> 
> In fact, this actually helps and would make it unnecessary to have separate
> folders! 

Are these folders unnecessary I am not too sure.

> I think you miss the point of why there are different folders.
> 
> There are different folders, because usually 32bit and 64bit builds from the
> _same_ source version usually have different timestamps. If you would have
> the cache in only a single directory and run 64bit and 32bit applications
> mixed, each would invalidate the cache if it was created from the other arch.
> 
> So if you run multiple archs and thery have the same timestamp (as you
> claim) you will not run into problems if different archs share the same
> cache folder.
> 
> As mentioned before, the arch is changing the content of the cache item as
> the content is defined by our GPU and not CPU.
Its not theory that different archs in debian do share identical timestamps. 
This is reality.

You are missing something important here Nouveau already picked up and started
using the shared util/disk_cache so its only a matter of time before one of the
software renderers do the same thing.

Tobias Droste so for the amd hardware I have there should not be a fatal issue
when the match up happens.   That is good to know.  Will that also apply in the
Nouveau we would have to ask and it is going to apply in every case that is
going to use the disk_cache code?   So this could come a bug that comes back
and bites in future.

Tobias step back look at the broader picture.   This is an area of common code
and need to be design not for one case but in fact for all.  Now if something
like this was inside just the AMD user-space library code everything would be
good if a promise was given that compatibility would be maintained.

I would still prefer each arch has there own cache directory in case one of the
archs has a suspect gcc or other complier and has in fact built the library
wrong.   So that only that archs application go splat.   Currently you have an
environmental to turn disc cache off extra option would be an environmental to
allow forcing using another cache location so that Multiarch can do
diagnostics.

You can look at each arch as it own build environment with its own bugs.

Turning the cache off is not exactly a solution.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170312/50af6708/attachment-0001.html>