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

Reply via email to