On 7/31/2015 8:36 PM, Chris Wilson wrote:
On Fri, Jul 31, 2015 at 08:12:30PM +0530, Goel, Akash wrote:
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;
};
Almost. You will need a backpointer from the node to the object so you
can do your list iteration and purge the unwanted object.
Agree that a back pointer is also needed, as the stolen structure will
not be embedded in the object structure. Thanks.
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=1094f92e6d94190cf1334fd9bd6459ab70801455
More thanks for providing the reference implementation.
Best regards
Akash
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
