* [PATCH] drm/i915: Restore all GGTT VMAs on resume
@ 2015-07-06 14:15 Tvrtko Ursulin
2015-07-06 15:19 ` Chris Wilson
2015-07-07 16:50 ` shuang.he
0 siblings, 2 replies; 8+ messages in thread
From: Tvrtko Ursulin @ 2015-07-06 14:15 UTC (permalink / raw)
To: Intel-gfx; +Cc: Daniel Vetter
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
When rotated and partial views were added no one spotted the resume
path which assumes only one GGTT VMA per object and hence is now
skipping rebind of alternative views.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
Similarly to my recent debugfs patch, it would seem quicker path could
be to walk GGTT active & inactive lists, but I assume we want to call
i915_gem_clflush_object only once per object which would make that
problematic.
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8cfa3906f440..5742a2a74cf8 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2543,6 +2543,8 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_object *obj;
struct i915_address_space *vm;
+ struct i915_vma *vma;
+ bool flush;
i915_check_and_clear_faults(dev);
@@ -2552,16 +2554,23 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev)
dev_priv->gtt.base.total,
true);
+ /* Cache flush objects bound into GGTT and rebind them. */
+ vm = &dev_priv->gtt.base;
list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list) {
- struct i915_vma *vma = i915_gem_obj_to_vma(obj,
- &dev_priv->gtt.base);
- if (!vma)
- continue;
+ flush = false;
+ list_for_each_entry(vma, &obj->vma_list, vma_link) {
+ if (vma->vm != vm)
+ continue;
- i915_gem_clflush_object(obj, obj->pin_display);
- WARN_ON(i915_vma_bind(vma, obj->cache_level, PIN_UPDATE));
- }
+ WARN_ON(i915_vma_bind(vma, obj->cache_level,
+ PIN_UPDATE));
+ flush = true;
+ }
+
+ if (flush)
+ i915_gem_clflush_object(obj, obj->pin_display);
+ }
if (INTEL_INFO(dev)->gen >= 8) {
if (IS_CHERRYVIEW(dev) || IS_BROXTON(dev))
--
2.4.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [PATCH] drm/i915: Restore all GGTT VMAs on resume
2015-07-06 14:15 [PATCH] drm/i915: Restore all GGTT VMAs on resume Tvrtko Ursulin
@ 2015-07-06 15:19 ` Chris Wilson
2015-07-06 15:29 ` Tvrtko Ursulin
2015-07-08 9:32 ` Daniel Vetter
2015-07-07 16:50 ` shuang.he
1 sibling, 2 replies; 8+ messages in thread
From: Chris Wilson @ 2015-07-06 15:19 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: Daniel Vetter, Intel-gfx
On Mon, Jul 06, 2015 at 03:15:01PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>
> When rotated and partial views were added no one spotted the resume
> path which assumes only one GGTT VMA per object and hence is now
> skipping rebind of alternative views.
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> ---
> Similarly to my recent debugfs patch, it would seem quicker path could
> be to walk GGTT active & inactive lists, but I assume we want to call
> i915_gem_clflush_object only once per object which would make that
> problematic.
It's a bit easier because there are no active entries after suspend, and
we may not care too much for over clflushing.
We should actually clear the GGTT of all but pinned entries on
hibernate (which would save a bunch of work on early resume), and there
are a bunch of non-objects inside the GGTT that should be evicted/restored
properly. (Would have been trivial had we made them all objects in the
first place.)
The patch is in the right direction and the other issues are present
irrespective of this patch.
I guess a begrudingly
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm/i915: Restore all GGTT VMAs on resume
2015-07-06 15:19 ` Chris Wilson
@ 2015-07-06 15:29 ` Tvrtko Ursulin
2015-07-06 15:39 ` Chris Wilson
2015-07-08 9:32 ` Daniel Vetter
1 sibling, 1 reply; 8+ messages in thread
From: Tvrtko Ursulin @ 2015-07-06 15:29 UTC (permalink / raw)
To: Chris Wilson, Intel-gfx, Tvrtko Ursulin, Daniel Vetter,
Joonas Lahtinen
On 07/06/2015 04:19 PM, Chris Wilson wrote:
> On Mon, Jul 06, 2015 at 03:15:01PM +0100, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> When rotated and partial views were added no one spotted the resume
>> path which assumes only one GGTT VMA per object and hence is now
>> skipping rebind of alternative views.
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>> ---
>> Similarly to my recent debugfs patch, it would seem quicker path could
>> be to walk GGTT active & inactive lists, but I assume we want to call
>> i915_gem_clflush_object only once per object which would make that
>> problematic.
>
> It's a bit easier because there are no active entries after suspend, and
> we may not care too much for over clflushing.
>
> We should actually clear the GGTT of all but pinned entries on
> hibernate (which would save a bunch of work on early resume), and there
> are a bunch of non-objects inside the GGTT that should be evicted/restored
> properly. (Would have been trivial had we made them all objects in the
> first place.)
What are these non-objects and where do I find the code with restores
them improperly?
> The patch is in the right direction and the other issues are present
> irrespective of this patch.
>
> I guess a begrudingly
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Thanks!
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm/i915: Restore all GGTT VMAs on resume
2015-07-06 15:29 ` Tvrtko Ursulin
@ 2015-07-06 15:39 ` Chris Wilson
0 siblings, 0 replies; 8+ messages in thread
From: Chris Wilson @ 2015-07-06 15:39 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: Daniel Vetter, Intel-gfx
On Mon, Jul 06, 2015 at 04:29:12PM +0100, Tvrtko Ursulin wrote:
>
> On 07/06/2015 04:19 PM, Chris Wilson wrote:
> >On Mon, Jul 06, 2015 at 03:15:01PM +0100, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>
> >>When rotated and partial views were added no one spotted the resume
> >>path which assumes only one GGTT VMA per object and hence is now
> >>skipping rebind of alternative views.
> >>
> >>Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>Cc: Chris Wilson <chris@chris-wilson.co.uk>
> >>Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> >>---
> >>Similarly to my recent debugfs patch, it would seem quicker path could
> >>be to walk GGTT active & inactive lists, but I assume we want to call
> >>i915_gem_clflush_object only once per object which would make that
> >>problematic.
> >
> >It's a bit easier because there are no active entries after suspend, and
> >we may not care too much for over clflushing.
> >
> >We should actually clear the GGTT of all but pinned entries on
> >hibernate (which would save a bunch of work on early resume), and there
> >are a bunch of non-objects inside the GGTT that should be evicted/restored
> >properly. (Would have been trivial had we made them all objects in the
> >first place.)
>
> What are these non-objects and where do I find the code with
> restores them improperly?
The PDEs are allocated directly in the GGTT and ignored completely
across hibernation. All we ideally need to do is evict them on freeze.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm/i915: Restore all GGTT VMAs on resume
2015-07-06 15:19 ` Chris Wilson
2015-07-06 15:29 ` Tvrtko Ursulin
@ 2015-07-08 9:32 ` Daniel Vetter
2015-07-08 9:45 ` Tvrtko Ursulin
1 sibling, 1 reply; 8+ messages in thread
From: Daniel Vetter @ 2015-07-08 9:32 UTC (permalink / raw)
To: Chris Wilson, Tvrtko Ursulin, Intel-gfx, Tvrtko Ursulin,
Daniel Vetter, Joonas Lahtinen
On Mon, Jul 06, 2015 at 04:19:01PM +0100, Chris Wilson wrote:
> On Mon, Jul 06, 2015 at 03:15:01PM +0100, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >
> > When rotated and partial views were added no one spotted the resume
> > path which assumes only one GGTT VMA per object and hence is now
> > skipping rebind of alternative views.
> >
> > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > ---
> > Similarly to my recent debugfs patch, it would seem quicker path could
> > be to walk GGTT active & inactive lists, but I assume we want to call
> > i915_gem_clflush_object only once per object which would make that
> > problematic.
Patch is missing offending commit that introduce this issue and which
platforms are affected (I guess all due to partial view?). Also should be
cc: stable I presume?
Can you please supply this so I can ammend the commit message? Applied to
-fixes meanwhile, thanks.
-Daniel
>
> It's a bit easier because there are no active entries after suspend, and
> we may not care too much for over clflushing.
>
> We should actually clear the GGTT of all but pinned entries on
> hibernate (which would save a bunch of work on early resume), and there
> are a bunch of non-objects inside the GGTT that should be evicted/restored
> properly. (Would have been trivial had we made them all objects in the
> first place.)
>
> The patch is in the right direction and the other issues are present
> irrespective of this patch.
>
> I guess a begrudingly
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm/i915: Restore all GGTT VMAs on resume
2015-07-08 9:32 ` Daniel Vetter
@ 2015-07-08 9:45 ` Tvrtko Ursulin
2015-07-08 9:57 ` Daniel Vetter
0 siblings, 1 reply; 8+ messages in thread
From: Tvrtko Ursulin @ 2015-07-08 9:45 UTC (permalink / raw)
To: Daniel Vetter, Chris Wilson, Intel-gfx, Tvrtko Ursulin,
Daniel Vetter, Joonas Lahtinen
On 07/08/2015 10:32 AM, Daniel Vetter wrote:
> On Mon, Jul 06, 2015 at 04:19:01PM +0100, Chris Wilson wrote:
>> On Mon, Jul 06, 2015 at 03:15:01PM +0100, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>
>>> When rotated and partial views were added no one spotted the resume
>>> path which assumes only one GGTT VMA per object and hence is now
>>> skipping rebind of alternative views.
>>>
>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>>> ---
>>> Similarly to my recent debugfs patch, it would seem quicker path could
>>> be to walk GGTT active & inactive lists, but I assume we want to call
>>> i915_gem_clflush_object only once per object which would make that
>>> problematic.
>
> Patch is missing offending commit that introduce this issue and which
> platforms are affected (I guess all due to partial view?). Also should be
> cc: stable I presume?
>
> Can you please supply this so I can ammend the commit message? Applied to
> -fixes meanwhile, thanks.
Ha, "offending" commits. In the sense of that the bug only manifests
when they are present they are either of these two:
commit c5ad54cf7dd8922bd1cee2d5871aebf73dc9638e
Author: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Date: Wed May 6 14:36:09 2015 +0300
drm/i915: Use partial view in mmap fault handler
commit 3b7a5119b5d2def1161226a4c6a643db537dff7e
Author: Sonika Jindal <sonika.jindal@intel.com>
Date: Fri Apr 10 14:37:29 2015 +0530
drm/i915/skl: Support for 90/270 rotation
But they are just the tips of two longish streams of developments
so they should not necessarily be viewed as offending towards the
respective authors. They are just final feature enablements.
All platforms are affected due to partial views I suppose, although I am
not sure if they are actually used/triggered in the field. That's why I
was not sure should stable be copied.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH] drm/i915: Restore all GGTT VMAs on resume
2015-07-08 9:45 ` Tvrtko Ursulin
@ 2015-07-08 9:57 ` Daniel Vetter
0 siblings, 0 replies; 8+ messages in thread
From: Daniel Vetter @ 2015-07-08 9:57 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: Daniel Vetter, Intel-gfx
On Wed, Jul 08, 2015 at 10:45:23AM +0100, Tvrtko Ursulin wrote:
>
> On 07/08/2015 10:32 AM, Daniel Vetter wrote:
> >On Mon, Jul 06, 2015 at 04:19:01PM +0100, Chris Wilson wrote:
> >>On Mon, Jul 06, 2015 at 03:15:01PM +0100, Tvrtko Ursulin wrote:
> >>>From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>>
> >>>When rotated and partial views were added no one spotted the resume
> >>>path which assumes only one GGTT VMA per object and hence is now
> >>>skipping rebind of alternative views.
> >>>
> >>>Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>>Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>>Cc: Chris Wilson <chris@chris-wilson.co.uk>
> >>>Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> >>>---
> >>>Similarly to my recent debugfs patch, it would seem quicker path could
> >>>be to walk GGTT active & inactive lists, but I assume we want to call
> >>>i915_gem_clflush_object only once per object which would make that
> >>>problematic.
> >
> >Patch is missing offending commit that introduce this issue and which
> >platforms are affected (I guess all due to partial view?). Also should be
> >cc: stable I presume?
> >
> >Can you please supply this so I can ammend the commit message? Applied to
> >-fixes meanwhile, thanks.
>
> Ha, "offending" commits. In the sense of that the bug only manifests
> when they are present they are either of these two:
>
> commit c5ad54cf7dd8922bd1cee2d5871aebf73dc9638e
> Author: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Date: Wed May 6 14:36:09 2015 +0300
>
> drm/i915: Use partial view in mmap fault handler
>
> commit 3b7a5119b5d2def1161226a4c6a643db537dff7e
> Author: Sonika Jindal <sonika.jindal@intel.com>
> Date: Fri Apr 10 14:37:29 2015 +0530
>
> drm/i915/skl: Support for 90/270 rotation
>
> But they are just the tips of two longish streams of developments
> so they should not necessarily be viewed as offending towards the respective
> authors. They are just final feature enablements.
>
> All platforms are affected due to partial views I suppose, although I am not
> sure if they are actually used/triggered in the field. That's why I was not
> sure should stable be copied.
Well commits are only in 4.2, so -fixes is ok.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] drm/i915: Restore all GGTT VMAs on resume
2015-07-06 14:15 [PATCH] drm/i915: Restore all GGTT VMAs on resume Tvrtko Ursulin
2015-07-06 15:19 ` Chris Wilson
@ 2015-07-07 16:50 ` shuang.he
1 sibling, 0 replies; 8+ messages in thread
From: shuang.he @ 2015-07-07 16:50 UTC (permalink / raw)
To: shuang.he, lei.a.liu, intel-gfx, tvrtko.ursulin
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Task id: 6731
-------------------------------------Summary-------------------------------------
Platform Delta drm-intel-nightly Series Applied
ILK 302/302 302/302
SNB 312/316 312/316
IVB 345/345 345/345
BYT -2 289/289 287/289
HSW 382/382 382/382
-------------------------------------Detailed-------------------------------------
Platform Test drm-intel-nightly Series Applied
*BYT igt@gem_partial_pwrite_pread@reads PASS(1) FAIL(1)
*BYT igt@gem_partial_pwrite_pread@reads-uncached PASS(1) FAIL(1)
Note: You need to pay more attention to line start with '*'
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-07-08 9:54 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-07-06 14:15 [PATCH] drm/i915: Restore all GGTT VMAs on resume Tvrtko Ursulin
2015-07-06 15:19 ` Chris Wilson
2015-07-06 15:29 ` Tvrtko Ursulin
2015-07-06 15:39 ` Chris Wilson
2015-07-08 9:32 ` Daniel Vetter
2015-07-08 9:45 ` Tvrtko Ursulin
2015-07-08 9:57 ` Daniel Vetter
2015-07-07 16:50 ` shuang.he
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox