On 31 August 2018 at 11:37, Timothy Arceri <tarc...@itsqueeze.com> wrote: > On 31/08/18 20:10, Emil Velikov wrote: >> >> Hi Timothy, >> >> On 31 August 2018 at 10:57, Timothy Arceri <tarc...@itsqueeze.com> wrote: >>> >>> On 31/08/18 19:40, Bas Nieuwenhuizen wrote: >>>> >>>> >>>> +TImothy >>>> >>>> On Fri, Aug 31, 2018 at 11:32 AM Alexander Larsson <al...@redhat.com> >>>> wrote: >>>>> >>>>> >>>>> >>>>> Hi, I'm the developer behind flatpak (https://flatpak.org/) and we've >>>>> recently run into some issues with the mesa shader cache. Flatpak has >>>>> a app/runtime split where the runtime is shared between app and >>>>> provides /usr. The runtime contains a version of mesa, but this can be >>>>> overridden by runtime extensions to add other OpenGL drivers. >>>>> >>>>> Each app has a separate $XDG_CACHE_HOME, pointing into the per-app >>>>> writable storage. For example, gedit has >>>>> XDG_CACHE_HOME="/home/alex/.var/app/org.gnome.gedit/cache". This >>>>> causes mesa to store the shader cache per-app in >>>>> $XDG_CACHE_HOME/mesa_shader_cache. >>>>> >>>>> In the regular case this works fine, but sometimes the version of mesa >>>>> is changed, with the shader cache being left in place. For example, >>>>> sometimes we update the mesa version in the runtime, and sometimes the >>>>> app switches to a new runtime which has a different mesa version. >>>>> >>>>> Such updates have caused a lot of issues for us, ranging from direct >>>>> crashes at startup as in >>>>> https://github.com/flatpak/flatpak/issues/2052 and sometimes just >>>>> super-slow performance. In all cases, blowing away the shader cache >>>>> directory fixed all issues. >>>>> >>>>> The steam flatpak has a bunch of workaround for the cache: >>>>> >>>>> >>>>> https://github.com/flathub/com.valvesoftware.Steam/blob/master/steam_wrapper/steam_wrapper.py#L35 >>>>> But we can't expect every app to do this. >>>>> >>>>> So, my question is, is the cache supposed to be backward compatible, >>>>> or at least versioned? Are we missing something in our mesa builds to >>>>> make that work? Is this fixed somewhere with a patch i can backport? >>>>> And if not, do we need to add some magic to flatpak to automatically >>>>> clean up the shader cache after an update? >>>> >>>> >>>> >>>> It is supposed to be versioned automatically by mesa. >>>> >>> >>> Hi Alexander, >>> >>> We depend on build timestamps of the mesa/llvm binaries when generating >>> the >>> sha for cache items. So if flatpak results in two versions of mesa having >>> the same timestamp then there is likely going to be issues. >>> >>> static inline bool >>> disk_cache_get_function_timestamp(void *ptr, uint32_t* timestamp) >>> { >>> Dl_info info; >>> struct stat st; >>> if (!dladdr(ptr, &info) || !info.dli_fname) { >>> return false; >>> } >>> if (stat(info.dli_fname, &st)) { >>> return false; >>> } >>> *timestamp = st.st_mtime; >>> return true; >>> } >>> >> Have you tried using the build-id from src/util/build_id.c? >> > > Hi Emil, > > Honestly I've got no idea what that code does. Maybe someone who does could > write patches to switch to it along with an explanation of why its better. > Even just adding some comments in that file would be helpful. > > I don't want to be the one responsible for it (and any new issues with the > cache) when I'm not aware of how it works :( > In a few words - retrieves the unique, in our case sha1, for the binary. Any change in Mesa source will lead to a different build-id. The SO thread has longer/better explanation [1]. You can skim through git log for details and poke contributors with specific questions.
HTH Emil [1] https://stackoverflow.com/questions/29856780/what-is-nt-gnu-build-id-used-for _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
