llvmpipe: limit the number of fragment shader variants kept around
authorRoland Scheidegger <sroland@vmware.com>
Fri, 18 Jun 2010 12:52:17 +0000 (13:52 +0100)
committerRoland Scheidegger <sroland@vmware.com>
Fri, 18 Jun 2010 12:52:17 +0000 (13:52 +0100)
commit17c9d7eea7b3365c59455a731fcb81e69bb86ce2
treedf310fae3d03ba8f7f4dbc8bedbb6a74709b45a9
parentff8e1452df5c86e745aea0490e9c6afdf166407b
llvmpipe: limit the number of fragment shader variants kept around

llvmpipe can create a large number of shader variants for a single shader
(which are quite big), and they were only ever deleted if the shader itself
was deleted. This is especially apparent in things like glean
blendFunc where a new variant is created for every different subtest, chewing
up all memory.
This change limits the numbers of fragment shader variants (for all shaders)
which are kept around to a fixed number. If that would be exceeded a fixed
portion of the cached variants is deleted (since without tracking the used
variants this involves flushing we don't want to delete only one).
Always the least recently used variants (from all shaders together) are
deleted.
For now this is all per-context.
Both the number of how many variants are cached (1024) as well as how many
will be deleted at once (1/4 of the cache size) are just rough guesses and
subject to further optimization.
src/gallium/drivers/llvmpipe/lp_context.c
src/gallium/drivers/llvmpipe/lp_context.h
src/gallium/drivers/llvmpipe/lp_limits.h
src/gallium/drivers/llvmpipe/lp_state_fs.c
src/gallium/drivers/llvmpipe/lp_state_fs.h