[PATCH xserver 2/4] glamor: Reduce BO cache size to 16 MB
Max Staudt
mstaudt at suse.de
Fri Jul 15 13:46:22 UTC 2016
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 <mstaudt at 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
More information about the xorg-devel
mailing list