Skip to content

iris: Delete shader variants when deleting the API-facing shader

Kenneth Graunke requested to merge kwg/mesa:iris-shader-delete-defer into master

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: ed4ffb97 ("iris: rework program cache interface")

Merge request reports