On 22.01.2018 15:16, Nicolai Hähnle wrote:
On 19.01.2018 07:05, Tapani Pälli wrote:
On 01/18/2018 05:49 PM, Nicolai Hähnle wrote:
On 17.01.2018 17:10, Tapani Pälli wrote:
On 17.01.2018 13:34, Nicolai Hähnle wrote:
On 15.01.2018 13:31, Tapani Pälli wrote:
Hello;
Here's a refactored series of EGL_ANDROID_blob_cache. Now cache
functions are stored in disk_cache struct and the functionality
called within existing disk_cache put/get code. Problems/errors
that existed with earlier series are gone.
On Android cache index file is created to MESA_GLSL_CACHE_DIR
and blobs are generated under '/data/user_de/0' in application
specific paths:
Can't we let the "cache index" be managed by the ANDROID_blob_cache
as well? That seems to me more in the spirit of what that extension
is about, and would avoid polluting stuff like /sdcard.
The cache index file is used for two purposes:
- Keeping track of the size of the cache. This use is obsoleted
enterely by ANDROID_blob_cache.
- Keeping track of keys where only their presence is relevant and
no data is associated. These could easily be treated as empty (0
byte sized) blobs.
I guess it could be possible, for every app we would create index
when disk_cache gets created. I guess only issue could be that
Android might go and remove the index from cache when it decides to
resize it and then we would loose it even though there would be
items in cache. I can try how this would work.
Entries can be kicked out of the on-disk index (which is really a bit
of a misnomer) as well if there's a hash collision.
I believe this functionality is only used as a marker to indicate
that the GLSL compile step can be skipped. So losing an entry in
there shouldn't cause any damage.
What I meant is that if we would store index by using set() function,
the index itself would be just another entry for Android's cache, it
can decide to remove it when it manages cache size.
Not sure if we're talking about the same thing, then? What I meant was
that every call to disk_cache_put_key becomes a call to the
Android-provided set() function, and every call to disk_cache_has_key
becomes a call to the get() function.
Sorry for the confusion, this is how I implemented it now for the
current new set I sent.
Although storing the index itself in the blob cache is also an
interesting idea.
Cheers,
Nicolai
Cheers,
Nicolai
Cheers,
Nicolai
androidia_64:/ # find /data/user_de/0/ -name *shader*
/data/user_de/0/com.android.settings/code_cache/com.android.opengl.shaders_cache
/data/user_de/0/com.android.gallery3d/code_cache/com.android.opengl.shaders_cache
/data/user_de/0/com.android.systemui/code_cache/com.android.opengl.shaders_cache
/data/user_de/0/com.rovio.angrybirdsspace.ads/code_cache/com.android.opengl.shaders_cache
(this part is managed by Android but may be interesting to know).
Also SurfaceFlinger manages its own cache as seen in the log output:
01-15 07:40:26.329 2129 2129 D SurfaceFlinger: shader cache
generated - 24 shaders in 57.687504 ms
I'm not sure if /sdcard is sane default but I've tried everything
else (/cache, /data/cache) and failed because of permission errors.
Thanks;
Tapani Pälli (7):
dri: add interface for EGL_ANDROID_blob_cache extension
egl: add support for EGL_ANDROID_blob_cache
disk cache: add callback functionality
disk cache: support setting MESA_GLSL_CACHE_DIR at compile time
i965: add __DRI2_BLOB support and set cache functions
android: ignore MESA_GLSL_CACHE_DISABLE setting
android: set '/sdcard/' as MESA_GLSL_CACHE_DIR by default
Android.common.mk | 1 +
include/GL/internal/dri_interface.h | 26 +++++++++++++-
src/egl/drivers/dri2/egl_dri2.c | 43
++++++++++++++++++++++++
src/egl/drivers/dri2/egl_dri2.h | 4 +++
src/egl/main/eglapi.c | 29 ++++++++++++++++
src/egl/main/eglapi.h | 4 +++
src/egl/main/egldisplay.h | 3 ++
src/egl/main/eglentrypoint.h | 1 +
src/mesa/drivers/dri/i965/brw_disk_cache.c | 2 ++
src/mesa/drivers/dri/i965/intel_screen.c | 21 ++++++++++++
src/util/disk_cache.c | 54
+++++++++++++++++++++++++++++-
src/util/disk_cache.h | 19 +++++++++++
12 files changed, 205 insertions(+), 2 deletions(-)
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
