> 
> Hi Eric,
> 
> others: This may be a larger problem (I'd be interested in how TTM solves 
> this also).
> 
> So I've hit a problem with the fake bufmgr and the size of the objects 
> referenced by a batchbuffer being bigger than the current aperture. So 
> when we have a batchbuffer and we are emitting a number of operations, the 
> list of references buffers becomes > 32MB for me and we fall down in a 
> heap (compiz can do this really easy...)
> 
> My first hack involved failing the relocation emit and falling back and 
> having the caller flush the current batchbuffer and retry, however this 
> fails on i915 as the only place we emit the relocs is in the middle of a 
> state emission, so we would need to rollback and re-do the state emit.
> 
> I'm just thinking of ways to fix it, we could pre-validate all the buffers 
> in i915_vtbl.c that we reference and keep a list of buffers that are on 
> the list and flush and fallback at that point, however this involves some 
> changes to the bufmgr interface, and fake internals...

Okay because I'm nice and really really need this working I've committed a 
fix for fake bufmgr with support for 915, Eric please review this, and if 
you get time please explain how I could make 965 work, as I'll be trying 
that tomorrow.

Dave.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to