On 7/29/2015 5:34 PM, Chris Wilson wrote:
On Mon, Jul 27, 2015 at 11:38:13AM +0200, Daniel Vetter wrote:
Chris and I just discussed on irc that the bound_list isn't in a great LRU
order right now and Chris sent out a fix for that. But it only works if we
preferrentially shrink inactive objects first. Worth the bother or just a
FIXME? For the fb use-case alone it's not needed since we can't remove the
fb until it's no longer being displayed (otherwise the backwards-compat
code kicks in and synchronously kills the display at RMFB time), and that
pretty much means we can't put the underlying bo into any cache (and mark
it purgeable) either. But a FIXME comment here would be good for sure,
just in case this assumption ever gets broken.
I've been mucking around with patch a bit (with contexts-from-stolen
reenabled) and the list ierators used here are terrible; severely
impacting our allocations by a few orders of magnitude (imagine having
just the ggtt full of 4k objects, let alone several ppgtt all full of
their own bound 4k objetcs).
To combat this will require a special purgeable list maintaind by
madv(), and subclassing the struct drm_mm_node to hold our extra
details.
Should we add a separate purgeable list for stolen objects ?
/** Stolen memory for this object, instead of being backed by shmem. */
- struct drm_mm_node *stolen;
+ struct i915_gem_stolen *stolen;
struct i915_gem_stolen {
struct drm_mm_node *node;
struct list_head purge_list;
};
Best regards
Akash
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
