[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 #7 from oiaohm at gmail.com ---
<b>Please outline a particular usage scenario that would suffer from this.</b>

I do run some x32 ABI programs so I have syscall.x32=y set in boot-loader under
Debian.   These are build x32 ABI because they are opengl and what they are
doing can take days to complete.  So small percentage of difference is
important.   The fact the current patch calls x32 and i386 the same is wrong.  
When my mesa updates I am going to have cache failure that was why cache
feature was disabled in the first place.

Yes debian ships with x32 compliers the kernel is x32 enabled just turned off
by default.  For us who have turned it on the defect in Mesa not detect x32 is
going to cause us head aches.

https://wiki.debian.org/QemuUserEmulation

Next my system is debian multi-arch as started with Debian normal qemu user
emulation set-up.   My system is i386 amd64 with x32 enabled and with arm64
installed as well by multiarch.

https://cgit.freedesktop.org/mesa/mesa/commit/?id=11f0efec2e615f5233defdd8ca9693c54ea49b1f
The reality here is the patch I have pointed to does not fix the bug.   It fix
the bug in 1 case only.

The cases where you are running x32 it does not support.   The cases where you
are running multiarch the the patch I pointed to does not support.   So its
basically broken.   Does a case of a person using x32 or multiarch behave the
same with it constantly nuking cache the answer is yes.   So the patch is
nothing more than a part fix.

https://patchwork.freedesktop.org/patch/141891/
Where this patch by Darren Salt is a full fix for more usage cases than my 2
cases. 

In fact a person testing multi versions of mesa could put the version
difference into the triplet so avoid when running two versions of mesa at the
same time on the same on the arch them stopping all over each other cache.

So Darren Salt patch fixes my 2 use cases and 3 case.

I had not considered Jan Vesely case of running like 2 64 bit version of mesa
at the same time in different programs and the include patch did not allow for
that instead that would make mesa return to nuke the cache all the time why
disk_cache was disabled by default.

Darren Salt patch might not be absolutely perfect for Jan Vesely case but a
person with Jan Vesely case has a workaround with it that they don't have with
the existing.


Just like mine the Jan Vesely issue exist because 
https://cgit.freedesktop.org/mesa/mesa/commit/?id=11f0efec2e615f5233defdd8ca9693c54ea49b1f
is badly written code disobeying conventions and not covering enough usage
cases.

What because I did not list out a usage case straight up I should not bother
reporting bugs?  Where the problem is breach of convention that will be causing
more than 1 problem. 

Almost everywhere in a code base you find if( sizeof(void *) == 4 ) being used
to work out bit width of a system is wrong.

The reason why I pushed it up to critical instead of minor is if you change the
directory once mesa with disc caching is production deployed you may leave
behind a directory that never gets deleted.   So the cache storage directory is
something we need to right now.   In fact I would say that this deserves to be
pushed to blocker until fixed.   This is a mistake that should not have entered
the code base in the first place as its a patch is a hack not well considered
code.

-- 
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/20170308/a7bb14b9/attachment.html>