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... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG ------------------------------------------------------------------------- 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
