| Message ID | 1379689502-7462-1-git-send-email-benjamin.widawsky@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Sep 20, 2013 at 08:05:02AM -0700, Ben Widawsky wrote: > Context save and restore is by definition a slow process, however it is > also an infrequent process. Don't try to optimize the save restore at > the cost of any of our precious cache space. Contexts begin to get quite > large on HSW and beyond. Infrequent? > At least for benchmarks people seem to care about, there is almost > always only 1 context running, which means I don't expect this to do any > harm. For benchmarks with many contexts, there could be performance > degradation - but I have a sneaking suspicion the HW will do some fancy > magic to speak up context save & restores anyway. There are at least 2 contexts in every benchmark QA cares about. It wasn't like making them L3 objects in the first place was motivated by benchmark results... Anyway the idea was to see if QA still notice a difference... -Chris
On Fri, Sep 20, 2013 at 04:12:37PM +0100, Chris Wilson wrote: > On Fri, Sep 20, 2013 at 08:05:02AM -0700, Ben Widawsky wrote: > > Context save and restore is by definition a slow process, however it is > > also an infrequent process. Don't try to optimize the save restore at > > the cost of any of our precious cache space. Contexts begin to get quite > > large on HSW and beyond. > > Infrequent? Relative to operations which use the cache. > > > At least for benchmarks people seem to care about, there is almost > > always only 1 context running, which means I don't expect this to do any > > harm. For benchmarks with many contexts, there could be performance > > degradation - but I have a sneaking suspicion the HW will do some fancy > > magic to speak up context save & restores anyway. > > There are at least 2 contexts in every benchmark QA cares about. It > wasn't like making them L3 objects in the first place was motivated by > benchmark results... > No, I've no doubt it was motivated by benchmarks, but I think making it L3 (which I still have a hard time believe would do at all what it's intended to do) would only prove further that not wasting LLC space is a good thing. The theory follows that not wasting L3 space is also a good thing. > Anyway the idea was to see if QA still notice a difference... > -Chris > I'll try to be an optimist for once.
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index 26c3fcc..593be55 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -153,13 +153,10 @@ create_hw_context(struct drm_device *dev, return ERR_PTR(-ENOMEM); } - if (INTEL_INFO(dev)->gen >= 7) { - ret = i915_gem_object_set_cache_level(ctx->obj, - I915_CACHE_L3_LLC); - /* Failure shouldn't ever happen this early */ - if (WARN_ON(ret)) - goto err_out; - } + ret = i915_gem_object_set_cache_level(ctx->obj, I915_CACHE_NONE); + /* Failure shouldn't ever happen this early */ + if (WARN_ON(ret)) + goto err_out; /* The ring associated with the context object is handled by the normal * object tracking code. We give an initial ring value simple to pass an
Context save and restore is by definition a slow process, however it is also an infrequent process. Don't try to optimize the save restore at the cost of any of our precious cache space. Contexts begin to get quite large on HSW and beyond. At least for benchmarks people seem to care about, there is almost always only 1 context running, which means I don't expect this to do any harm. For benchmarks with many contexts, there could be performance degradation - but I have a sneaking suspicion the HW will do some fancy magic to speak up context save & restores anyway. CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Eero Tamminen <eero.t.tamminen@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> --- drivers/gpu/drm/i915/i915_gem_context.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-)