With the previous size, we would quickly accumulate >1GB of unused memory.
This was because the code didn't take into account: - Pixels usually take 4 bytes these days, not 1 byte. - BOs are allocated larger than the actual width*height used. - Few GPUs have this much VRAM and the cache easily makes them run into GL_OUT_OF_MEMORY. Reproducible by moving large windows outside the visible area and back in. glamor_copy_fbo_fbo_temp() will allocate a large temporary buffer, which is "freed" into the cache. The GPU will quickly run out of VRAM, as every redraw of the window dragging may allocate megabytes of memory. Signed-off-by: Max Staudt <msta...@suse.de> --- glamor/glamor_fbo.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/glamor/glamor_fbo.c b/glamor/glamor_fbo.c index f80c20d..b27f652 100644 --- a/glamor/glamor_fbo.c +++ b/glamor/glamor_fbo.c @@ -36,7 +36,14 @@ #define GLAMOR_CACHE_EXACT_SIZE 1 //#define NO_FBO_CACHE 1 -#define FBO_CACHE_THRESHOLD (256*1024*1024) + +/* Assume 4 bytes per pixel when calculating cache size. + * Since glamor_pixmap_fbo_cache_put() calculates the size of a BO as + * width*height, we take the pixel size into account here. + * Note that actual BOs are somewhat larger -- we ignore this as an + * approximate cache limit is sufficient. + */ +#define FBO_CACHE_THRESHOLD (16*1024*1024 / 4) /* Loop from the tail to the head. */ #define xorg_list_for_each_entry_reverse(pos, head, member) \ -- 2.6.6 _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
