[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 #35 from oiaohm at gmail.com ---
(In reply to Marek Olšák from comment #34)
> Your argument for keeping the GPU and build IDs out of the hash because of
> the possibility of collisions has one flaw: The probability of a collision
> doesn't grow when the cache is already full (if the number of items in the
> cache remains the same).

Sorry Marek you have your maths wrong you have missed something important
predictability of collisions.

The build_id particularly.  As this is a changing value.  When you put this in
the hash this does increase the risk of a collision not detected in program
development.

So you tested program with X build version no collisions in the hashes.   That
you merge build-id into sha the program is running with Y build version and now
due to insane bad luck the Y build-id value being different has caused a
collision that the programmer who made the program has no clue about.   So now
users using Y version are reporting problems that developer does not have and
is left totally confused.

So possibility of collisions has barely changed by merging build-id into hash. 
But how predictable a collision will be has changed massively.   Yet you still
see people making these arguments without the mathematics behind it.   
Predictability of when a collision is going to happen has altered massively by
merging the build-id so making collisions a lot more of a random event to
debug.

Reality you should avoid throwing changing values into hashes where you can as
this adds extra level of unpredictability.  With new optimisations to in ways
shaders are generated there is enough risk of collisions without making them
unpredictable.

gpu-id are less likely to be a cause and should be testable for by a developer.

Basically it bad enough to have a collision without giving it a
pseudorandomness factor.   I should have been more clear what I meant by
altering risk.   Altering risk for those attempting to provide working programs
to end users.   Making collision pseudorandom is not a useful feature not
helpful to those making programs.   A predictable hash collision developer of
program could possibly work around by not making anything that does that.

So please do remember hash collision have two factors.  Possibility and
Predictability.  A good hash solution for a cache decreases the possibility of
collision without being insanely unpredictable in case of collision if it ever
happens.  If you only look at Possibility you complete end up creating yourself
the worse cases if hash collision does happen.

> It's a bad idea to wipe the cache on a driver or GPU switch, because DRI PRIME
> (hybrid graphics) switches between 2 GPUs all the time.

I agree with this.  Its also a bad idea not to be able to clean cache when a
GPU is removed for good.   This is the main reason why I suggest keeping the
gpu-id exposed not hidden in a hash.

Also not being able to clean out items out of the cache for build_id or gpu_id
you are no longer using also increases risk of a collision version to version.

Design a system to clean the cache is just as important as making the cache.  
Yes wiping the cache on driver change is over cleaning.   Under cleaning is
also bad.   The issue is getting the right balance.

-- 
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/20170313/9836a0e1/attachment.html>