iris: Delete shader variants when deleting the API-facing shader
authorKenneth Graunke <kenneth@whitecape.org>
Wed, 5 Jun 2019 20:12:58 +0000 (13:12 -0700)
committerKenneth Graunke <kenneth@whitecape.org>
Wed, 29 Jul 2020 18:34:01 +0000 (11:34 -0700)
commit128cbcd3a7ba543d644ed3189dcd668900b270f4
treed124aa084a412b13e6b871b10b03a6aa429aa15c
parent9a49d4c2db054b75babbb6d683d4f7622aed5eaf
iris: Delete shader variants when deleting the API-facing shader

We were space-leaking iris_compiled_shader objects, leaving them around
basically forever - long after the associated iris_uncompiled_shader was
deleted.  Perhaps even more importantly, this left the BO containing the
assembly referenced, meaning those were never reclaimed either.  For
long running applications, this can leak quite a bit of memory.

Now, when freeing iris_uncompiled_shader, we hunt down any associated
iris_compiled_shader objects and pitch those (and their BO) as well.

One issue is that the shader variants can still be bound, because we
haven't done a draw that updates the compiled shaders yet.  This can
cause issues because state changes want to look at the old program to
know what to flag dirty.  It's a bit tricky to get right, so instead
we defer variant deletion until the shaders are properly unbound, by
stashing them on a "dead" list and tidying that each time we try and
delete some shader variants.

This ensures long running programs delete their shaders eventually.

Fixes: ed4ffb97158 ("iris: rework program cache interface")
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6075>
src/gallium/drivers/iris/iris_context.h
src/gallium/drivers/iris/iris_program.c
src/gallium/drivers/iris/iris_program_cache.c