Dave Airlie wrote: > 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. > > Dave, At least for TTM this is part of a larger problem where you can hit problems both when the pinned page quota is hit, and when you can't fit an object in the aperture.
The pinned page quota exceeded is a nasty error, since it can happen anywhere from the driver's point of view and is thus highly undesirable. The proposed solution is to pre-allocate all pinned quota associated with a buffer object and only fail during buffer creation, fence creation and mapping. The only non-fatal reason for execbuf failure is "signal received" and out-of-aperture space. Fence creation failures are dealt with by idling the hardware and return a NULL fence. The other problem is the one you mention. Since we're dealing with multiple clients and only evict one buffer at a time at aperture space-shortage and even may have pinned buffers scattered in the aperture, there is a probability that the execbuf call will fail with -ENOMEM. I guess before doing that, the kernel could retry and evict all evictable buffers before starting validation. That would eliminate all fragmentation issues except those arising from pinned buffers. The problem remains how to avoid this situation completely. I guess the drm driver can reserve a global "safe" aperture size, and communicate that to the 3D client, but the current TTM drivers don't deal with this situation. My first idea would probably be your first alternative. Flush and re-do the state-emit if the combined buffer size is larger than the "safe" aperture size. /Thomas ------------------------------------------------------------------------- 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
