On Mon, Aug 27, 2012 at 8:58 PM, Kenneth Graunke <kenn...@whitecape.org> wrote: > On 08/27/2012 03:00 PM, Stéphane Marchesin wrote: >> On Mon, Aug 27, 2012 at 2:24 PM, Kenneth Graunke >> <k...@kemper.freedesktop.org> wrote: >>> Module: Mesa >>> Branch: master >>> Commit: 87cdefed405da1a57a006737297d20ba0c25fa1b >>> URL: >>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=87cdefed405da1a57a006737297d20ba0c25fa1b >>> >>> Author: Kenneth Graunke <kenn...@whitecape.org> >>> Date: Sun Aug 26 00:07:56 2012 -0700 >>> >>> i965: Double the size of the state cache. >>> >>> We probably want to do something more sophisticated here, but this at >>> least makes it through L4D2 without dumping the program cache. >>> >>> Signed-off-by: Kenneth Graunke <kenn...@whitecape.org> >>> Reviewed-by: Eric Anholt <e...@anholt.net> >>> >>> --- >>> >>> src/mesa/drivers/dri/i965/brw_state_cache.c | 4 ++-- >>> 1 files changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/src/mesa/drivers/dri/i965/brw_state_cache.c >>> b/src/mesa/drivers/dri/i965/brw_state_cache.c >>> index 57a5ee9..8823b22 100644 >>> --- a/src/mesa/drivers/dri/i965/brw_state_cache.c >>> +++ b/src/mesa/drivers/dri/i965/brw_state_cache.c >>> @@ -372,10 +372,10 @@ brw_clear_cache(struct brw_context *brw, struct >>> brw_cache *cache) >>> void >>> brw_state_cache_check_size(struct brw_context *brw) >>> { >>> - /* un-tuned guess. Each object is generally a page, so 1000 of them is >>> 4 MB of >>> + /* un-tuned guess. Each object is generally a page, so 2000 of them is >>> 8 MB of >> >> The problem is that this statement ("Each object is generally a page") is >> wrong. >> >> A wm prog cache entry always contains prog_data as aux data. >> brw_wm_prog_data has those two fields: >> const float *param[MAX_UNIFORMS * 4]; /* should be: BRW_MAX_CURBE */ >> const float *pull_param[MAX_UNIFORMS * 4]; >> >> MAX_UNIFORMS is 4096. So in 64 bit, brw_wm_prog_data is more than 256k. >> >> Therefore by doubling the cache, you are going from 256 MB to 512 MB, >> not 4 MB to 8 MB. As far as I know, that cache is the biggest consumer >> of memory in i965. >> >> Stéphane > > Ouch! Clearly, having 32768 pointers in the key is absurd...especially > since programs usually only use a few uniforms. > > Thankfully, Eric has a three patch series which fixes the problem by > dynamically allocating the arrays: > http://lists.freedesktop.org/archives/mesa-dev/2012-August/026403.html >
Thanks, I'll look at those. > Hopefully that will land soon. I can revert the patch in the meantime > if you would prefer. Nah, if a proper solution is coming then I don't care :) Stéphane _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
