for symtom 1 desribed in commet #43(In reply to comment #33)
> To summarize:
> There seems two symptoms:
> 1. systems memories used by graphics driver will keep growing for a few times
> of resize operation, then drops dramatically, then grow again, and drops again
> ... If resize many times in very short time, it will consume all system memory
> and get X not resposible.
> 2. serious memory leak with composite, which will make graphics driver
> comsuming all system memory.
> on my Q35, I see neither of them
> on G45 and GM45, I see <1>, disable buffer reuse doesn't help here. it's
> desribed in comment #31
> on aspire one, I see <2>, disable buffer reuse doesn't help here. it's desribed
> in comment #32
>
For the symptom <1>, it seems it's the result of 965 state cache.
I have tracked it with valgrind (with VALGRIND_PRINTF_BACKTRACE), following is one of the buffer object I checked, you can see buffer object 474 is allocated when a window is created, and this buffer object is deleted much later in brw_clear_cache
**6022** shuang 443 alloc: handle=474, size=256 KB
==6022== at 0x5511171: VALGRIND_PRINTF_BACKTRACE (valgrind.h:3695)
==6022== by 0x5511CF8: drm_intel_gem_bo_alloc_internal (intel_bufmgr_gem.c:437)
==6022== by 0x550D473: drm_intel_bo_alloc_for_render (intel_bufmgr.c:58)
==6022== by 0x52978AE: intel_region_alloc (intel_regions.c:173)
==6022== by 0x52968A1: intel_miptree_create (intel_mipmap_tree.c:122)
==6022== by 0x52B761B: intelTexImage (intel_tex_image.c:132)
==6022== by 0x52B80CD: intelTexImage2D (intel_tex_image.c:587)
==6022== by 0x5370B19: _mesa_TexImage2D (teximage.c:2676)
==6022== by 0x45A021D: (within /usr/lib/tmp/libclutter-glx-0.9.so.0.903.0)
==6022== by 0x45A04E8: cogl_texture_new_from_data (in /usr/lib/tmp/libclutter-glx-0.9.so.0.903.0)
==6022== by 0x80A8F2F: (within /usr/bin/metacity)
==6022== by 0x80A9112: (within /usr/bin/metacity)
**6022** shuang 6130 delete: handle=474, size=256 KB
==6022== at 0x5511171: VALGRIND_PRINTF_BACKTRACE (valgrind.h:3695)
==6022== by 0x551131E: drm_intel_gem_bo_unreference_locked (intel_bufmgr_gem.c:573)
==6022== by 0x55112AD: drm_intel_gem_bo_unreference_locked (intel_bufmgr_gem.c:582)
==6022== by 0x55112AD: drm_intel_gem_bo_unreference_locked (intel_bufmgr_gem.c:582)
==6022== by 0x5511791: drm_intel_gem_bo_unreference (intel_bufmgr_gem.c:621)
==6022== by 0x550D4B5: drm_intel_bo_unreference (intel_bufmgr.c:73)
==6022== by 0x52D0B2A: brw_clear_cache (brw_state_cache.c:501)
==6022== by 0x52D8C8C: brw_note_unlock (brw_vtbl.c:184)
==6022== by 0x528C43B: UNLOCK_HARDWARE (intel_context.c:1078)
==6022== by 0x52C58EA: brw_draw_prims (brw_draw.c:417)
==6022== by 0x538E59B: vbo_exec_DrawRangeElements (vbo_exec_array.c:435)
==6022== by 0x5382EB9: neutral_DrawRangeElements (vtxfmt_tmp.h:343)
If I reduced the limit of cached items, this symptom will disappear:
diff --git a/src/mesa/drivers/dri/i965/brw_state_cache.c b/src/mesa/drivers/dri/i965/brw_state_cache.c
index e40d7a0..0afb7af 100644
--- a/src/mesa/drivers/dri/i965/brw_state_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_state_cache.c
@@ -527,10 +527,10 @@ brw_state_cache_check_size(struct brw_context *brw)
/* un-tuned guess. We've got around 20 state objects for a total of around
* 32k, so 1000 of them is around 1.5MB.
*/
- if (brw->cache.n_items > 1000)
+ if (brw->cache.n_items > 100) brw_clear_cache(brw, &brw->cache);
- if (brw->surface_cache.n_items > 1000)
+ if (brw->surface_cache.n_items > 100) brw_clear_cache(brw, &brw->surface_cache);
}
for symtom 1 desribed in commet #43(In reply to comment #33)
> To summarize:
> There seems two symptoms:
> 1. systems memories used by graphics driver will keep growing for a few times
> of resize operation, then drops dramatically, then grow again, and drops again
> ... If resize many times in very short time, it will consume all system memory
> and get X not resposible.
> 2. serious memory leak with composite, which will make graphics driver
> comsuming all system memory.
> on my Q35, I see neither of them
> on G45 and GM45, I see <1>, disable buffer reuse doesn't help here. it's
> desribed in comment #31
> on aspire one, I see <2>, disable buffer reuse doesn't help here. it's desribed
> in comment #32
>
For the symptom <1>, it seems it's the result of 965 state cache. PRINTF_ BACKTRACE) , following is one of the buffer object I checked, you can see buffer object 474 is allocated when a window is created, and this buffer object is deleted much later in brw_clear_cache
I have tracked it with valgrind (with VALGRIND_
**6022** shuang 443 alloc: handle=474, size=256 KB PRINTF_ BACKTRACE (valgrind.h:3695) gem_bo_ alloc_internal (intel_ bufmgr_ gem.c:437) bo_alloc_ for_render (intel_bufmgr.c:58) regions. c:173) create (intel_ mipmap_ tree.c: 122) tex_image. c:132) tex_image. c:587) tmp/libclutter- glx-0.9. so.0.903. 0) new_from_ data (in /usr/lib/ tmp/libclutter- glx-0.9. so.0.903. 0)
==6022== at 0x5511171: VALGRIND_
==6022== by 0x5511CF8: drm_intel_
==6022== by 0x550D473: drm_intel_
==6022== by 0x52978AE: intel_region_alloc (intel_
==6022== by 0x52968A1: intel_miptree_
==6022== by 0x52B761B: intelTexImage (intel_
==6022== by 0x52B80CD: intelTexImage2D (intel_
==6022== by 0x5370B19: _mesa_TexImage2D (teximage.c:2676)
==6022== by 0x45A021D: (within /usr/lib/
==6022== by 0x45A04E8: cogl_texture_
==6022== by 0x80A8F2F: (within /usr/bin/metacity)
==6022== by 0x80A9112: (within /usr/bin/metacity)
**6022** shuang 6130 delete: handle=474, size=256 KB PRINTF_ BACKTRACE (valgrind.h:3695) gem_bo_ unreference_ locked (intel_ bufmgr_ gem.c:573) gem_bo_ unreference_ locked (intel_ bufmgr_ gem.c:582) gem_bo_ unreference_ locked (intel_ bufmgr_ gem.c:582) gem_bo_ unreference (intel_ bufmgr_ gem.c:621) bo_unreference (intel_bufmgr.c:73) cache.c: 501) context. c:1078) DrawRangeElemen ts (vbo_exec_ array.c: 435) DrawRangeElemen ts (vtxfmt_tmp.h:343)
==6022== at 0x5511171: VALGRIND_
==6022== by 0x551131E: drm_intel_
==6022== by 0x55112AD: drm_intel_
==6022== by 0x55112AD: drm_intel_
==6022== by 0x5511791: drm_intel_
==6022== by 0x550D4B5: drm_intel_
==6022== by 0x52D0B2A: brw_clear_cache (brw_state_
==6022== by 0x52D8C8C: brw_note_unlock (brw_vtbl.c:184)
==6022== by 0x528C43B: UNLOCK_HARDWARE (intel_
==6022== by 0x52C58EA: brw_draw_prims (brw_draw.c:417)
==6022== by 0x538E59B: vbo_exec_
==6022== by 0x5382EB9: neutral_
If I reduced the limit of cached items, this symptom will disappear:
diff --git a/src/mesa/ drivers/ dri/i965/ brw_state_ cache.c b/src/mesa/ drivers/ dri/i965/ brw_state_ cache.c drivers/ dri/i965/ brw_state_ cache.c drivers/ dri/i965/ brw_state_ cache.c cache_check_ size(struct brw_context *brw)
brw_clear_ cache(brw, &brw->cache);
index e40d7a0..0afb7af 100644
--- a/src/mesa/
+++ b/src/mesa/
@@ -527,10 +527,10 @@ brw_state_
/* un-tuned guess. We've got around 20 state objects for a total of around
* 32k, so 1000 of them is around 1.5MB.
*/
- if (brw->cache.n_items > 1000)
+ if (brw->cache.n_items > 100)
- if (brw->surface_ cache.n_ items > 1000) cache.n_ items > 100)
brw_clear_ cache(brw, &brw->surface_ cache);
+ if (brw->surface_
}