[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 #37 from oiaohm at gmail.com ---
(In reply to Marek Olšák from comment #36)
> The build id and GPU id can be compared directly after the hash lookup and
> decompression to prevent collisions when two shaders with different IDs have
> the same hash. Thus we only have to worry about collisions between shaders
> having the same IDs.

This read we will deal with a collisions instead of avoiding collisions by
using more cpu cycles every time a shader is loaded this does not sound
particularly good for performance.

Build-id and gpu-id could be directories in the cache.   This would reduce the
number of entries you need to search for hits in and you would not find matches
with invalid values of build-id or gpu-id in the first place.   This means you
could skip checking for those value when loading a shader from cache because
only the correct files should in those directories unless user has done
something stupid.

If build-id and gpu-id were directories cache cleaning would be simpler.   Why
you could rm -rf the no longer required directories.   This would still keep
file names fairly clean.

Marek Olšák is really valid to waste cpu cycles checking Build-id and Gpu-id
when it can be done once when opening the directory to search for cache
entries.  I think not.   So I don't think build-id and gpu-id mixed into hash
would be a good thing.   

Build-id and gpu-id could be in the shader entries to detect if user has done
something bad to the cache with a audit tool but this is not something that has
to be run when a game is running.   But you do have to be careful with build-id
like appending the build-id on the end of the file past the point the hash was
calculated to so that collision are consistent.  Also keeping collision
possibilities consistent make it possible for application developers to work
around them if they ever happen.   

Performance does mean worrying about wasting cycles.   Reducing possibility of
collisions by design reduces how many cpu cycles you have to waste preventing
collision based errors.   You really don't want to have to be doing any extra
checks every time you access the cache thinking a shader cache should be
reasonably heavily used at times.

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