https://bugs.freedesktop.org/show_bug.cgi?id=100091
John changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #30 from John ---
That seems
https://bugs.freedesktop.org/show_bug.cgi?id=100091
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #28 from John ---
That seems to work indeed!
Thank you!
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #27 from Timothy Arceri ---
https://patchwork.freedesktop.org/series/21582/(In reply to John from comment
#26)
> Timothy, do you have any patch you'd like me to test?
>
> Thanks!
> John
This should do it:
https://patchwork.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #26 from John ---
Timothy, do you have any patch you'd like me to test?
Thanks!
John
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #25 from Timothy Arceri ---
After a bunch of discussion 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
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #24 from Emil Velikov ---
(In reply to Michel Dänzer from comment #23)
> (In reply to Emil Velikov from comment #19)
> > IMHO the [file] source of the timestamps is not the bigger mystery, but why
> > we end up with "no such file or
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #23 from Michel Dänzer ---
(In reply to Emil Velikov from comment #19)
> IMHO the [file] source of the timestamps is not the bigger mystery, but why
> we end up with "no such file or directory...---disabling".
Because the shader cac
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #22 from John ---
In case it helps, here are the calls for disk_cache_create (always called by
r600_disk_cache_create).
First when starting the Battle.Net launcher:
- Called for radeonsi_dri.so
- Called for d3dadapter9.so.1.0.0
- Ca
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #21 from John ---
(In reply to Emil Velikov from comment #20)
> I would really appreciate if one can spend 2 minutes and test the patch in
> question. Pretty please ?
>
> Do move/prune your cache and let me know if you still get the
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #20 from Emil Velikov ---
(In reply to John from comment #18)
> (In reply to Emil Velikov from comment #16)
> > Some ideas:
> > - a non-timestamp better solution might be applicable/in the works
> > (guessing here)
>
> A simple wor
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #19 from Emil Velikov ---
(In reply to Michel Dänzer from comment #17)
> Emil, I don't think there's any mystery anymore given comment 13 — the
> different cache timestamps are due to *_dri.so and d3dadapter9.so.1.0.0
> having differ
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #18 from John ---
(In reply to Emil Velikov from comment #16)
> Some ideas:
> - a non-timestamp better solution might be applicable/in the works
> (guessing here)
A simple workaround would be to use a combination of the timestamp a
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #17 from Michel Dänzer ---
Emil, I don't think there's any mystery anymore given comment 13 — the
different cache timestamps are due to *_dri.so and d3dadapter9.so.1.0.0 having
different timestamps.
(In reply to Emil Velikov from co
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #16 from Emil Velikov ---
Created attachment 130129
--> https://bugs.freedesktop.org/attachment.cgi?id=130129&action=edit
HACK: disable dynamic, enable symbolic
Some ideas:
- a non-timestamp better solution might be applicable/in
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #15 from John ---
(In reply to Edmondo Tommasina from comment #14)
> You could try to set the modified time to the so files as a workaround.
>
> Something like this:
>
> touch -m -t 20170808.00 /usr/lib32/d3d/d3dadapter9.so.1.0
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #14 from Edmondo Tommasina ---
You could try to set the modified time to the so files as a workaround.
Something like this:
touch -m -t 20170808.00 /usr/lib32/d3d/d3dadapter9.so.1.0.0
/usr/lib32/xorg/modules/dri/radeonsi_dri.so
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #13 from John ---
(In reply to John from comment #12)
> (In reply to Grazvydas Ignotas from comment #11)
> > Try this:
> > stat -c %Y d3d/d3dadapter9.so dri/radeonsi_dri.so
> >
> > although I'm not sure if TAHITI uses radeonsi_dri o
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #12 from John ---
(In reply to Grazvydas Ignotas from comment #11)
> Try this:
> stat -c %Y d3d/d3dadapter9.so dri/radeonsi_dri.so
>
> although I'm not sure if TAHITI uses radeonsi_dri or r600_dri.
1488874138
1488874151
The 2nd on
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #11 from Grazvydas Ignotas ---
Try this:
stat -c %Y d3d/d3dadapter9.so dri/radeonsi_dri.so
although I'm not sure if TAHITI uses radeonsi_dri or r600_dri.
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #10 from John ---
(In reply to Timothy Arceri from comment #9)
>
> Yeah that makes sense. It's probably grabbing a different time for nine vs
> opengl because they are separate dynamic libraries I'll take a look at this
> tomorrow.
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #9 from Timothy Arceri ---
(In reply to John from comment #8)
> (In reply to Grazvydas Ignotas from comment #5)
> > If you try to run the game again (without updating mesa), do you get the
> > exact same numbers or a new set?
> I get
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #8 from John ---
(In reply to Grazvydas Ignotas from comment #5)
> If you try to run the game again (without updating mesa), do you get the
> exact same numbers or a new set?
I get the same numbers.
1488874151_1488872775/ when start
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #7 from John ---
Oh I see, a timestamp.
Now I've seen something interesting.
I started B.Net and it created this folder:
~/.cache/mesa/32/1488874151_1488872775/
While launching SCII I saw some similar error message as before but
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #6 from Andy Furniss ---
(In reply to John from comment #0)
> Hello,
>
> I am on mesa-git, built from around 1AM this morning.
> This has the patches that add the 32/64b folders, but it's still not working
> in with the game StarCra
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #5 from Grazvydas Ignotas ---
(In reply to John from comment #0)
> Failed to create ~/.cache/mesa/64/1488793729_1488791612/AMD TAHITI/89 for
> shader cache (No such file or directory)---disabling.
> ...
> The issue is, as the messag
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #4 from Timothy Arceri ---
(In reply to John from comment #3)
> That's right I have both folders.
>
> How do you create the identifier? I find it quite strange that the folder's
> number on disk is only one away from the one expecte
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #3 from John ---
That's right I have both folders.
How do you create the identifier? I find it quite strange that the folder's
number on disk is only one away from the one expected. Last week when I
reported a similar issue on phoro
https://bugs.freedesktop.org/show_bug.cgi?id=100091
Timothy Arceri changed:
What|Removed |Added
Component|Drivers/Gallium/radeonsi|Mesa core
QA Contact|dri-devel
29 matches
Mail list logo
