aboutsummaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/llvmpipe/lp_limits.h
Commit message (Collapse)AuthorAgeFilesLines
* llvmpipe: change LP_MAX_SHADER_INSTRUCTIONS definitionRoland Scheidegger2014-08-211-1/+1
| | | | | | | | | | | | | This change will double cache size for branches which have a lower LP_MAX_SHADER_VARIANTS limit (it will not do anything on master). The reason is that nowadays shaders tend to be quite a bit larger than they were (they were big when llvmpipe didn't have a fs loop, got much smaller with that loop, and since then have gradually increased quite a bit though still smaller than without the fs loop for various reasons - among them being d3d10 compliance, usage of 8-wide vectors, non-swizzled blend code). Thus effectively less shaders would be cached (unless they were very small and the variant limit was hit first). Also, since we're getting rid of the IR nowadays, the cached shaders shouldn't need all that much memory actually.
* llvmpipe: change LP_MAX_SHADER_INSTRUCTIONS limit definition.Roland Scheidegger2014-05-081-1/+3
| | | | | | | | | | When the limit was changed to be defined in terms of LP_MAX_SHADER_VARIANTS (75f1fea14f524ef05e980d825fda3ae226ae2ffe) when it was increased, this inadvertently lowered the limit in some branches (that have a lower LP_MAX_SHADER_VARIANTS number) when merged. So, make sure the limit is always at least the number it once was. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: increase fs shader variant instruction cache limit by factor 4Roland Scheidegger2013-10-121-2/+2
| | | | | | | | | | | | | | | | | The previous limit of of 128*1024 was reported to cause frequent recompiles in some apps due to shader variant thrashing on IRC in some apps leading to noticeable lags. Note that the LP_MAX_SHADER_VARIANTS limit (1024) was more or less impossible to reach, since even simple fragment shaders without texturing (glxgears) used more than twice than 128 instructions, hence the instruction limit would have always been reached first (excluding things like trivial shaders not writing color). Even with the new limit it is VERY likely the instruction limit is hit first. Should help with such lags due to recompiles (though other shader types have their own limits, LP_MAX_SETUP_VARIANTS and DRAW_MAX_SHADER_VARIANTS, in particular the latter seems a bit small (128)). Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: bump 3d and cube map limits to 2048 and 8192 respectivelyRoland Scheidegger2013-06-061-2/+2
| | | | | | | These should just work, required by d3d10. Too large resources will get thrown out separately anyway. Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: bump LP_MAX_THREADS to 16Brian Paul2013-04-261-1/+1
| | | | | | | On the mesa-users list, Burlen Loring reported a speed-up with 16 cores and his test/app. Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: support array texturesRoland Scheidegger2012-11-291-0/+1
| | | | | | | | | | This adds array (1d,2d) texture support to llvmpipe. Though probably should do something about 1d array textures requiring gobs of memory (this issue is not strictly limited to arrays but it is probably worse there). Initial code by Jakob Bornecrantz <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* llvmpipe: set max cube texture size to 4K x 4KBrian Paul2012-09-171-0/+1
| | | | | | | | Before, the limit was 8K. For 32-bit RGBA that would be require 1.5 GB of memory (w/out mipmaps). That's well beyond the LP_MAX_TEXTURE_SIZE of 1GB. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: Bump the maximum texture size (in pixels).José Fonseca2012-08-281-2/+3
| | | | | | | | | | But cap the size in bytes, to avoid depleting the whole system memory, with humongus textures. Tested with max-texture-size piglit test. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: Trim the fragment shader cached based on LLVM IR instruction count.José Fonseca2011-12-081-0/+6
| | | | | | | | | | | | Number of fragment shader variants is not very representative of the memory used by LLVM, neither is number of shader instructions, as often texture sampling constitutes most of the generated code. This change adds an additional trim criteria: least recently used fragment shader variants will be freed until the total number of LLVM IR instruction falls below a specified threshold. Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: use llvm for attribute interpolant calculationKeith Whitwell2010-09-181-0/+10
| | | | | Basically no change relative to hard-coded version, but this will be useful for other changes later.
* llvmpipe: limit the number of fragment shader variants kept aroundRoland Scheidegger2010-06-181-0/+5
| | | | | | | | | | | | | | | | | | 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.
* llvmpipe: implement max scene sizeBrian Paul2010-04-271-0/+6
| | | | | | | | When the size of the scene (binned data plus referenced resources/textures) exceeds LP_MAX_SCENE_SIZE flush/render the scene. This could be improved in various ways but is a good start. Fixes piglit streaming-texture-leak test.
* llvmpipe: Move the determination of the number of threads to the screen.José Fonseca2010-04-241-0/+3
|
* llvmpipe: increase max 2D texture / surface size to 4K x 4KBrian Paul2010-04-231-1/+1
|
* llvmpipe: rename MAXWIDTH, MAXHEIGHTBrian Paul2010-04-231-2/+2
|
* llvmpipe: rename lp_tile_size.h to lp_limits.hBrian Paul2010-04-231-0/+61
Collect the various driver limits in one place since.