All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/2] drm/i915: introduce & use i915_gem_object_mark_dirty()
@ 2016-04-28 16:26 Dave Gordon
  2016-04-28 16:26 ` [PATCH 2/2] drm/i915: a couple more uses for i915_gem_object_mark_dirty() Dave Gordon
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Dave Gordon @ 2016-04-28 16:26 UTC (permalink / raw)
  To: intel-gfx

This just hides the existing obj->dirty flag inside a trivial inline
setter, to discourage non-GEM code from looking too closely.

Existing code that sets obj->dirty is then changed to use the function
instead.

Inspired-by: http://www.spinics.net/lists/intel-gfx/msg92390.html
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h            | 11 +++++++++++
 drivers/gpu/drm/i915/i915_gem.c            |  6 +++---
 drivers/gpu/drm/i915/i915_gem_context.c    |  2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c           |  6 +++---
 5 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 32f0597..dfa45ef 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3004,6 +3004,17 @@ static inline void i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
 	obj->pages_pin_count++;
 }
 
+/*
+ * Flag the object content as having changed since the last call to
+ * i915_gem_object_pin_pages() above, so that the new content is not
+ * lost after the next call to i915_gem_object_unpin_pages() below
+ */
+static inline void i915_gem_object_mark_dirty(struct drm_i915_gem_object *obj)
+{
+	WARN_ON(obj->pages_pin_count == 0);
+	obj->dirty = true;
+}
+
 static inline void i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
 {
 	BUG_ON(obj->pages_pin_count == 0);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d493e79..3fd8cb4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -931,9 +931,9 @@ int i915_gem_obj_prepare_shmem_read(struct drm_i915_gem_object *obj,
 	intel_fb_obj_invalidate(obj, ORIGIN_CPU);
 
 	i915_gem_object_pin_pages(obj);
+	i915_gem_object_mark_dirty(obj);
 
 	offset = args->offset;
-	obj->dirty = 1;
 
 	for_each_sg_page(obj->pages->sgl, &sg_iter, obj->pages->nents,
 			 offset >> PAGE_SHIFT) {
@@ -3791,7 +3791,7 @@ static bool i915_gem_valid_gtt_space(struct i915_vma *vma,
 	if (write) {
 		obj->base.read_domains = I915_GEM_DOMAIN_GTT;
 		obj->base.write_domain = I915_GEM_DOMAIN_GTT;
-		obj->dirty = 1;
+		i915_gem_object_mark_dirty(obj);
 	}
 
 	trace_i915_gem_object_change_domain(obj,
@@ -5362,7 +5362,7 @@ struct drm_i915_gem_object *
 	i915_gem_object_pin_pages(obj);
 	sg = obj->pages;
 	bytes = sg_copy_from_buffer(sg->sgl, sg->nents, (void *)data, size);
-	obj->dirty = 1;		/* Backing store is now out of date */
+	i915_gem_object_mark_dirty(obj); /* Backing store is out of date */
 	i915_gem_object_unpin_pages(obj);
 
 	if (WARN_ON(bytes != size)) {
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
index 4e12bae..69b8391 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -747,7 +747,7 @@ static int do_rcs_switch(struct drm_i915_gem_request *req)
 		 * able to defer doing this until we know the object would be
 		 * swapped, but there is no way to do that yet.
 		 */
-		from->legacy_hw_ctx.rcs_state->dirty = 1;
+		i915_gem_object_mark_dirty(from->legacy_hw_ctx.rcs_state);
 
 		/* obj is kept alive until the next request by its active ref */
 		i915_gem_object_ggtt_unpin(from->legacy_hw_ctx.rcs_state);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 6f4f2a6..584b329 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1109,7 +1109,7 @@ static bool only_mappable_for_reloc(unsigned int flags)
 		u32 old_read = obj->base.read_domains;
 		u32 old_write = obj->base.write_domain;
 
-		obj->dirty = 1; /* be paranoid  */
+		i915_gem_object_mark_dirty(obj); /* be paranoid  */
 		obj->base.write_domain = obj->base.pending_write_domain;
 		if (obj->base.write_domain == 0)
 			obj->base.pending_read_domains |= obj->base.read_domains;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2b7e6bb..15d341e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2451,7 +2451,7 @@ static u32 intel_lr_indirect_ctx_offset(struct intel_engine_cs *engine)
 		DRM_DEBUG_DRIVER("Could not map object pages! (%d)\n", ret);
 		return ret;
 	}
-	ctx_obj->dirty = true;
+	i915_gem_object_mark_dirty(ctx_obj);
 
 	/* The second page of the context object contains some fields which must
 	 * be set up prior to the first execution. */
@@ -2735,9 +2735,9 @@ void intel_lr_context_reset(struct drm_i915_private *dev_priv,
 		if (WARN_ON(IS_ERR(vaddr)))
 			continue;
 
-		reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
-		ctx_obj->dirty = true;
+		i915_gem_object_mark_dirty(ctx_obj);
 
+		reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
 		reg_state[CTX_RING_HEAD+1] = 0;
 		reg_state[CTX_RING_TAIL+1] = 0;
 
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [PATCH 2/2] drm/i915: a couple more uses for i915_gem_object_mark_dirty()
  2016-04-28 16:26 [PATCH 1/2] drm/i915: introduce & use i915_gem_object_mark_dirty() Dave Gordon
@ 2016-04-28 16:26 ` Dave Gordon
  2016-04-28 16:36   ` Chris Wilson
  2016-04-28 16:34 ` [PATCH 1/2] drm/i915: introduce & use i915_gem_object_mark_dirty() Chris Wilson
  2016-04-28 17:48 ` ✗ Fi.CI.BAT: warning for series starting with [1/2] " Patchwork
  2 siblings, 1 reply; 10+ messages in thread
From: Dave Gordon @ 2016-04-28 16:26 UTC (permalink / raw)
  To: intel-gfx

intel_pin_and_map_ringbuffer_obj() should have been setting the dirty
flag, but wasn't; and the LRC code in intel_lr_context_do_pin() is also
updated to use the new function.

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
---
 drivers/gpu/drm/i915/intel_lrc.c        | 10 +++++-----
 drivers/gpu/drm/i915/intel_ringbuffer.c |  1 +
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 15d341e..707aec0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1098,17 +1098,17 @@ static int intel_lr_context_do_pin(struct intel_context *ctx,
 		goto unpin_ctx_obj;
 	}
 
-	lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
-
 	ret = intel_pin_and_map_ringbuffer_obj(engine->dev, ringbuf);
 	if (ret)
 		goto unpin_map;
 
-	ctx->engine[engine->id].lrc_vma = i915_gem_obj_to_ggtt(ctx_obj);
-	intel_lr_context_descriptor_update(ctx, engine);
+	i915_gem_object_mark_dirty(ctx_obj);
+
+	lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
 	lrc_reg_state[CTX_RING_BUFFER_START+1] = ringbuf->vma->node.start;
 	ctx->engine[engine->id].lrc_reg_state = lrc_reg_state;
-	ctx_obj->dirty = true;
+	ctx->engine[engine->id].lrc_vma = i915_gem_obj_to_ggtt(ctx_obj);
+	intel_lr_context_descriptor_update(ctx, engine);
 
 	/* Invalidate GuC TLB. */
 	if (i915.enable_guc_submission)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 66f69cd..22a703e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2145,6 +2145,7 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device *dev,
 
 	ringbuf->virtual_start = addr;
 	ringbuf->vma = i915_gem_obj_to_ggtt(obj);
+	i915_gem_object_mark_dirty(obj);
 	return 0;
 
 err_unpin:
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] drm/i915: introduce & use i915_gem_object_mark_dirty()
  2016-04-28 16:26 [PATCH 1/2] drm/i915: introduce & use i915_gem_object_mark_dirty() Dave Gordon
  2016-04-28 16:26 ` [PATCH 2/2] drm/i915: a couple more uses for i915_gem_object_mark_dirty() Dave Gordon
@ 2016-04-28 16:34 ` Chris Wilson
  2016-04-28 17:32   ` Dave Gordon
  2016-04-28 17:48 ` ✗ Fi.CI.BAT: warning for series starting with [1/2] " Patchwork
  2 siblings, 1 reply; 10+ messages in thread
From: Chris Wilson @ 2016-04-28 16:34 UTC (permalink / raw)
  To: Dave Gordon; +Cc: intel-gfx

On Thu, Apr 28, 2016 at 05:26:20PM +0100, Dave Gordon wrote:
> This just hides the existing obj->dirty flag inside a trivial inline
> setter, to discourage non-GEM code from looking too closely.
> 
> Existing code that sets obj->dirty is then changed to use the function
> instead.

I prefer set_dirty, unset_dirty, is_dirty which is what I used in my
patches.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 2/2] drm/i915: a couple more uses for i915_gem_object_mark_dirty()
  2016-04-28 16:26 ` [PATCH 2/2] drm/i915: a couple more uses for i915_gem_object_mark_dirty() Dave Gordon
@ 2016-04-28 16:36   ` Chris Wilson
  2016-04-28 17:20     ` Dave Gordon
  0 siblings, 1 reply; 10+ messages in thread
From: Chris Wilson @ 2016-04-28 16:36 UTC (permalink / raw)
  To: Dave Gordon; +Cc: intel-gfx

On Thu, Apr 28, 2016 at 05:26:21PM +0100, Dave Gordon wrote:
> intel_pin_and_map_ringbuffer_obj() should have been setting the dirty
> flag, but wasn't; and the LRC code in intel_lr_context_do_pin() is also
> updated to use the new function.

Technically it doesn't need to. Whilst there is any valid content in the
ringbuffer, it is pinned for use by requests and the hadware. Unlike the
context object whose content does need to persist when inactive.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 2/2] drm/i915: a couple more uses for i915_gem_object_mark_dirty()
  2016-04-28 16:36   ` Chris Wilson
@ 2016-04-28 17:20     ` Dave Gordon
  2016-04-28 17:27       ` Chris Wilson
  0 siblings, 1 reply; 10+ messages in thread
From: Dave Gordon @ 2016-04-28 17:20 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx

On 28/04/16 17:36, Chris Wilson wrote:
> On Thu, Apr 28, 2016 at 05:26:21PM +0100, Dave Gordon wrote:
>> intel_pin_and_map_ringbuffer_obj() should have been setting the dirty
>> flag, but wasn't; and the LRC code in intel_lr_context_do_pin() is also
>> updated to use the new function.
>
> Technically it doesn't need to. Whilst there is any valid content in the
> ringbuffer, it is pinned for use by requests and the hadware. Unlike the
> context object whose content does need to persist when inactive.
> -Chris

What about across suspend and/or hibernate? Any chance of there being 
valid (new) content in a ringbuffer that gets thrown away? Though 
presumably we insist that all pending work is completed before allowing 
hibernation/suspend anyway?

.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 2/2] drm/i915: a couple more uses for i915_gem_object_mark_dirty()
  2016-04-28 17:20     ` Dave Gordon
@ 2016-04-28 17:27       ` Chris Wilson
  0 siblings, 0 replies; 10+ messages in thread
From: Chris Wilson @ 2016-04-28 17:27 UTC (permalink / raw)
  To: Dave Gordon; +Cc: intel-gfx

On Thu, Apr 28, 2016 at 06:20:30PM +0100, Dave Gordon wrote:
> On 28/04/16 17:36, Chris Wilson wrote:
> >On Thu, Apr 28, 2016 at 05:26:21PM +0100, Dave Gordon wrote:
> >>intel_pin_and_map_ringbuffer_obj() should have been setting the dirty
> >>flag, but wasn't; and the LRC code in intel_lr_context_do_pin() is also
> >>updated to use the new function.
> >
> >Technically it doesn't need to. Whilst there is any valid content in the
> >ringbuffer, it is pinned for use by requests and the hadware. Unlike the
> >context object whose content does need to persist when inactive.
> >-Chris
> 
> What about across suspend and/or hibernate? Any chance of there
> being valid (new) content in a ringbuffer that gets thrown away?
> Though presumably we insist that all pending work is completed
> before allowing hibernation/suspend anyway?

Correct, before suspend we wait for all GPU work to be completed. We
don't want the GPU writing into memory after the suspend/hibernation
thinks we are ready. The pages are pinned by our activity as well.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 1/2] drm/i915: introduce & use i915_gem_object_mark_dirty()
  2016-04-28 16:34 ` [PATCH 1/2] drm/i915: introduce & use i915_gem_object_mark_dirty() Chris Wilson
@ 2016-04-28 17:32   ` Dave Gordon
  0 siblings, 0 replies; 10+ messages in thread
From: Dave Gordon @ 2016-04-28 17:32 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

On 28/04/16 17:34, Chris Wilson wrote:
> On Thu, Apr 28, 2016 at 05:26:20PM +0100, Dave Gordon wrote:
>> This just hides the existing obj->dirty flag inside a trivial inline
>> setter, to discourage non-GEM code from looking too closely.
>>
>> Existing code that sets obj->dirty is then changed to use the function
>> instead.
>
> I prefer set_dirty, unset_dirty, is_dirty which is what I used in my
> patches.
> -Chris

I wasn't going to abstract the test and clear operation because only GEM 
code needs those. In fact (apart from debugfs and error capture), only 
put_pages() implementations ever test or clear them.

Anyway, the real reason for sending this patchset was to see whether my 
local result was reproducible, namely that it will expose at least one 
path where an object is marked dirty while not pinned, in defiance of 
your previous comment about the invalidity of such an operation.

.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 10+ messages in thread

* ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: introduce & use i915_gem_object_mark_dirty()
  2016-04-28 16:26 [PATCH 1/2] drm/i915: introduce & use i915_gem_object_mark_dirty() Dave Gordon
  2016-04-28 16:26 ` [PATCH 2/2] drm/i915: a couple more uses for i915_gem_object_mark_dirty() Dave Gordon
  2016-04-28 16:34 ` [PATCH 1/2] drm/i915: introduce & use i915_gem_object_mark_dirty() Chris Wilson
@ 2016-04-28 17:48 ` Patchwork
  2016-04-28 18:36   ` Dave Gordon
  2 siblings, 1 reply; 10+ messages in thread
From: Patchwork @ 2016-04-28 17:48 UTC (permalink / raw)
  To: Dave Gordon; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/2] drm/i915: introduce & use i915_gem_object_mark_dirty()
URL   : https://patchwork.freedesktop.org/series/6491/
State : warning

== Summary ==

Series 6491v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/6491/revisions/1/mbox/

Test gem_busy:
        Subgroup basic-blt:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (hsw-brixbox)
        Subgroup basic-bsd:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (hsw-gt2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (hsw-brixbox)
                pass       -> DMESG-WARN (ilk-hp8440p)
        Subgroup basic-bsd1:
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (skl-nuci5)
        Subgroup basic-bsd2:
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (skl-nuci5)
        Subgroup basic-parallel-blt:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (hsw-gt2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (hsw-brixbox)
        Subgroup basic-parallel-bsd:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (hsw-gt2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (hsw-brixbox)
                pass       -> DMESG-WARN (ilk-hp8440p)
        Subgroup basic-parallel-bsd1:
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (skl-nuci5)
        Subgroup basic-parallel-bsd2:
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (skl-nuci5)
        Subgroup basic-parallel-render:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (hsw-gt2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (hsw-brixbox)
                pass       -> DMESG-WARN (ilk-hp8440p)
        Subgroup basic-parallel-vebox:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (hsw-gt2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (hsw-brixbox)
        Subgroup basic-render:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (hsw-brixbox)
                pass       -> DMESG-WARN (ilk-hp8440p)
        Subgroup basic-vebox:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (hsw-brixbox)
Test gem_cs_tlb:
        Subgroup basic-default:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (ilk-hp8440p)
                pass       -> DMESG-WARN (byt-nuc)
Test gem_exec_basic:
        Subgroup gtt-blt:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (hsw-gt2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (hsw-brixbox)
        Subgroup gtt-bsd:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (hsw-brixbox)
                pass       -> DMESG-WARN (ilk-hp8440p)
        Subgroup gtt-bsd1:
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (skl-nuci5)
        Subgroup gtt-bsd2:
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (skl-nuci5)
        Subgroup gtt-default:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (hsw-gt2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (hsw-brixbox)
                pass       -> DMESG-WARN (ilk-hp8440p)
        Subgroup gtt-render:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (hsw-gt2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (hsw-brixbox)
                pass       -> DMESG-WARN (ilk-hp8440p)
        Subgroup gtt-vebox:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (hsw-gt2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (hsw-brixbox)
Test gem_exec_parallel:
        Subgroup basic:
                dmesg-warn -> PASS       (ilk-hp8440p)
Test gem_exec_suspend:
        Subgroup basic-s3:
                pass       -> DMESG-WARN (ilk-hp8440p)
Test gem_mmap_gtt:
        Subgroup basic-small-bo:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (hsw-gt2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (hsw-brixbox)
                pass       -> DMESG-WARN (ilk-hp8440p)
        Subgroup basic-small-bo-tiledx:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (hsw-gt2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (hsw-brixbox)
                pass       -> DMESG-WARN (ilk-hp8440p)
        Subgroup basic-small-bo-tiledy:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (hsw-gt2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (hsw-brixbox)
                pass       -> DMESG-WARN (ilk-hp8440p)
        Subgroup basic-write-gtt:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (hsw-gt2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (hsw-brixbox)
                pass       -> DMESG-WARN (ilk-hp8440p)
        Subgroup basic-write-gtt-no-prefault:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (hsw-brixbox)
                pass       -> DMESG-WARN (ilk-hp8440p)
Test gem_render_tiled_blits:
        Subgroup basic:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (hsw-gt2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (hsw-brixbox)
Test gem_storedw_loop:
        Subgroup basic-blt:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (byt-nuc)
        Subgroup basic-bsd:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (byt-nuc)
        Subgroup basic-default:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (byt-nuc)
        Subgroup basic-render:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (byt-nuc)
        Subgroup basic-vebox:
                pass       -> DMESG-WARN (bsw-nuc-2)
Test gem_sync:
        Subgroup basic-render:
                pass       -> DMESG-WARN (ilk-hp8440p)
Test kms_frontbuffer_tracking:
        Subgroup basic:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (skl-nuci5)
                pass       -> DMESG-WARN (bdw-nuci7-2)
                pass       -> DMESG-WARN (hsw-gt2)
                pass       -> DMESG-WARN (bdw-ultra)
                pass       -> DMESG-WARN (skl-i7k-2)
                pass       -> DMESG-WARN (ivb-t430s)
                pass       -> DMESG-WARN (byt-nuc)
                pass       -> DMESG-WARN (snb-x220t)
                pass       -> DMESG-WARN (hsw-brixbox)
Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-c:
                incomplete -> PASS       (hsw-gt2)

bdw-nuci7-2      total:201  pass:163  dwarn:26  dfail:0   fail:0   skip:12 
bdw-ultra        total:201  pass:156  dwarn:20  dfail:0   fail:0   skip:25 
bsw-nuc-2        total:200  pass:133  dwarn:26  dfail:0   fail:0   skip:41 
byt-nuc          total:200  pass:137  dwarn:22  dfail:0   fail:0   skip:41 
hsw-brixbox      total:201  pass:155  dwarn:20  dfail:0   fail:0   skip:26 
hsw-gt2          total:201  pass:159  dwarn:20  dfail:0   fail:1   skip:21 
ilk-hp8440p      total:201  pass:125  dwarn:15  dfail:0   fail:0   skip:61 
ivb-t430s        total:201  pass:153  dwarn:17  dfail:0   fail:0   skip:31 
skl-i7k-2        total:201  pass:154  dwarn:20  dfail:0   fail:0   skip:27 
skl-nuci5        total:201  pass:164  dwarn:26  dfail:0   fail:0   skip:11 
snb-x220t        total:201  pass:144  dwarn:15  dfail:0   fail:1   skip:41 
snb-dellxps failed to collect. IGT log at Patchwork_2105/snb-dellxps/igt.log

Results at /archive/results/CI_IGT_test/Patchwork_2105/

1101e5fcc2634b10522eb50d0342a25d8e8266e8 drm-intel-nightly: 2016y-04m-28d-16h-43m-10s UTC integration manifest
cf935be drm/i915: introduce & use i915_gem_object_mark_dirty()

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: introduce & use i915_gem_object_mark_dirty()
  2016-04-28 17:48 ` ✗ Fi.CI.BAT: warning for series starting with [1/2] " Patchwork
@ 2016-04-28 18:36   ` Dave Gordon
  2016-05-02  8:58     ` Daniel Vetter
  0 siblings, 1 reply; 10+ messages in thread
From: Dave Gordon @ 2016-04-28 18:36 UTC (permalink / raw)
  To: intel-gfx, Chris Wilson

On 28/04/16 18:48, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: introduce & use i915_gem_object_mark_dirty()
> URL   : https://patchwork.freedesktop.org/series/6491/
> State : warning
>
> == Summary ==
>
> Series 6491v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/6491/revisions/1/mbox/
>
> Test gem_busy:
>          Subgroup basic-blt:
>                  pass       -> DMESG-WARN (bsw-nuc-2)
>                  pass       -> DMESG-WARN (skl-nuci5)
>                  pass       -> DMESG-WARN (bdw-nuci7-2)
>                  pass       -> DMESG-WARN (ivb-t430s)
>                  pass       -> DMESG-WARN (bdw-ultra)
>                  pass       -> DMESG-WARN (skl-i7k-2)
>                  pass       -> DMESG-WARN (byt-nuc)
>                  pass       -> DMESG-WARN (snb-x220t)
>                  pass       -> DMESG-WARN (hsw-brixbox)

Well, that's as expected: it's hitting the WARN_ON() that I put in there 
to check on usage of obj->dirty vs. pages_pin_count. Stack traces are 
all the same, like this one:

[   72.459223] ------------[ cut here ]------------
[   72.459254] WARNING: CPU: 0 PID: 6012 at 
drivers/gpu/drm/i915/i915_drv.h:3027 
i915_gem_object_set_to_gtt_domain+0x21c/0x280 [i915]
[   72.459255] WARN_ON(obj->pages_pin_count == 0)
[   72.459256] Modules linked in:
[   72.459257]  snd_hda_codec_hdmi snd_hda_intel i915 
x86_pkg_temp_thermal snd_hda_codec snd_hwdep snd_hda_core 
intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul mei_me lpc_ich 
ghash_clmulni_intel mei snd_pcm r8169 mii
[   72.459266] CPU: 0 PID: 6012 Comm: gem_busy Tainted: G        W 
  4.6.0-rc5-CI-Patchwork_2105+ #1
[   72.459267] Hardware name: Gigabyte Technology Co., Ltd. 
H87M-D3H/H87M-D3H, BIOS F11 08/18/2015
[   72.459268]  0000000000000000 ffff880212053c80 ffffffff8140de35 
ffff880212053cd0
[   72.459270]  0000000000000000 ffff880212053cc0 ffffffff81079c8c 
00000bd312e5a980
[   72.459272]  ffff880212e5a980 0000000000000001 ffff8800d7c70000 
0000000000000000
[   72.459274] Call Trace:
[   72.459277]  [<ffffffff8140de35>] dump_stack+0x67/0x92
[   72.459280]  [<ffffffff81079c8c>] __warn+0xcc/0xf0
[   72.459281]  [<ffffffff81079cfa>] warn_slowpath_fmt+0x4a/0x50
[   72.459293]  [<ffffffffa01efacb>] ? 
i915_gem_object_flush_cpu_write_domain.part.47+0x14b/0x1b0 [i915]
[   72.459303]  [<ffffffffa01f113c>] 
i915_gem_object_set_to_gtt_domain+0x21c/0x280 [i915]
[   72.459313]  [<ffffffffa01f128e>] 
i915_gem_set_domain_ioctl+0xee/0x160 [i915]
[   72.459315]  [<ffffffff815282ed>] drm_ioctl+0x13d/0x590
[   72.459325]  [<ffffffffa01f11a0>] ? 
i915_gem_object_set_to_gtt_domain+0x280/0x280 [i915]
[   72.459327]  [<ffffffff81199ba7>] ? handle_mm_fault+0x47/0x1e90
[   72.459329]  [<ffffffff811ee38a>] do_vfs_ioctl+0x8a/0x670
[   72.459331]  [<ffffffff811fa21a>] ? __fget_light+0x6a/0x90
[   72.459332]  [<ffffffff811ee9ac>] SyS_ioctl+0x3c/0x70
[   72.459333]  [<ffffffff817dc7a9>] entry_SYSCALL_64_fastpath+0x1c/0xac
[   72.459334] ---[ end trace 156adc997a22f992 ]---

So, is that a bug, marking an object dirty when pages_pin_count is 0? 
Does that mean that a program can set a BO to the GTT domain (or the CPU 
domain?), update its contents, and then it gets paged out due to memory 
pressure and the updates are lost?

Or ... no, I think the problem scenario would be
* set to GTT => mark dirty
* BO paged out => flushed to swap, marked clean
* BO paged in => still clean
* update contents => still clean?
* get paged out => not written out?

Or are we guaranteed to hit another mark_dirty during the process of 
updating the contents of the paged-in buffer?

.Dave.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: introduce & use i915_gem_object_mark_dirty()
  2016-04-28 18:36   ` Dave Gordon
@ 2016-05-02  8:58     ` Daniel Vetter
  0 siblings, 0 replies; 10+ messages in thread
From: Daniel Vetter @ 2016-05-02  8:58 UTC (permalink / raw)
  To: Dave Gordon; +Cc: intel-gfx

On Thu, Apr 28, 2016 at 07:36:32PM +0100, Dave Gordon wrote:
> On 28/04/16 18:48, Patchwork wrote:
> >== Series Details ==
> >
> >Series: series starting with [1/2] drm/i915: introduce & use i915_gem_object_mark_dirty()
> >URL   : https://patchwork.freedesktop.org/series/6491/
> >State : warning
> >
> >== Summary ==
> >
> >Series 6491v1 Series without cover letter
> >http://patchwork.freedesktop.org/api/1.0/series/6491/revisions/1/mbox/
> >
> >Test gem_busy:
> >         Subgroup basic-blt:
> >                 pass       -> DMESG-WARN (bsw-nuc-2)
> >                 pass       -> DMESG-WARN (skl-nuci5)
> >                 pass       -> DMESG-WARN (bdw-nuci7-2)
> >                 pass       -> DMESG-WARN (ivb-t430s)
> >                 pass       -> DMESG-WARN (bdw-ultra)
> >                 pass       -> DMESG-WARN (skl-i7k-2)
> >                 pass       -> DMESG-WARN (byt-nuc)
> >                 pass       -> DMESG-WARN (snb-x220t)
> >                 pass       -> DMESG-WARN (hsw-brixbox)
> 
> Well, that's as expected: it's hitting the WARN_ON() that I put in there to
> check on usage of obj->dirty vs. pages_pin_count. Stack traces are all the
> same, like this one:
> 
> [   72.459223] ------------[ cut here ]------------
> [   72.459254] WARNING: CPU: 0 PID: 6012 at
> drivers/gpu/drm/i915/i915_drv.h:3027
> i915_gem_object_set_to_gtt_domain+0x21c/0x280 [i915]
> [   72.459255] WARN_ON(obj->pages_pin_count == 0)
> [   72.459256] Modules linked in:
> [   72.459257]  snd_hda_codec_hdmi snd_hda_intel i915 x86_pkg_temp_thermal
> snd_hda_codec snd_hwdep snd_hda_core intel_powerclamp coretemp
> crct10dif_pclmul crc32_pclmul mei_me lpc_ich ghash_clmulni_intel mei snd_pcm
> r8169 mii
> [   72.459266] CPU: 0 PID: 6012 Comm: gem_busy Tainted: G        W
> 4.6.0-rc5-CI-Patchwork_2105+ #1
> [   72.459267] Hardware name: Gigabyte Technology Co., Ltd.
> H87M-D3H/H87M-D3H, BIOS F11 08/18/2015
> [   72.459268]  0000000000000000 ffff880212053c80 ffffffff8140de35
> ffff880212053cd0
> [   72.459270]  0000000000000000 ffff880212053cc0 ffffffff81079c8c
> 00000bd312e5a980
> [   72.459272]  ffff880212e5a980 0000000000000001 ffff8800d7c70000
> 0000000000000000
> [   72.459274] Call Trace:
> [   72.459277]  [<ffffffff8140de35>] dump_stack+0x67/0x92
> [   72.459280]  [<ffffffff81079c8c>] __warn+0xcc/0xf0
> [   72.459281]  [<ffffffff81079cfa>] warn_slowpath_fmt+0x4a/0x50
> [   72.459293]  [<ffffffffa01efacb>] ?
> i915_gem_object_flush_cpu_write_domain.part.47+0x14b/0x1b0 [i915]
> [   72.459303]  [<ffffffffa01f113c>]
> i915_gem_object_set_to_gtt_domain+0x21c/0x280 [i915]
> [   72.459313]  [<ffffffffa01f128e>] i915_gem_set_domain_ioctl+0xee/0x160
> [i915]
> [   72.459315]  [<ffffffff815282ed>] drm_ioctl+0x13d/0x590
> [   72.459325]  [<ffffffffa01f11a0>] ?
> i915_gem_object_set_to_gtt_domain+0x280/0x280 [i915]
> [   72.459327]  [<ffffffff81199ba7>] ? handle_mm_fault+0x47/0x1e90
> [   72.459329]  [<ffffffff811ee38a>] do_vfs_ioctl+0x8a/0x670
> [   72.459331]  [<ffffffff811fa21a>] ? __fget_light+0x6a/0x90
> [   72.459332]  [<ffffffff811ee9ac>] SyS_ioctl+0x3c/0x70
> [   72.459333]  [<ffffffff817dc7a9>] entry_SYSCALL_64_fastpath+0x1c/0xac
> [   72.459334] ---[ end trace 156adc997a22f992 ]---
> 
> So, is that a bug, marking an object dirty when pages_pin_count is 0? Does
> that mean that a program can set a BO to the GTT domain (or the CPU
> domain?), update its contents, and then it gets paged out due to memory
> pressure and the updates are lost?
> 
> Or ... no, I think the problem scenario would be
> * set to GTT => mark dirty
> * BO paged out => flushed to swap, marked clean
> * BO paged in => still clean
> * update contents => still clean?
> * get paged out => not written out?
> 
> Or are we guaranteed to hit another mark_dirty during the process of
> updating the contents of the paged-in buffer?

I didn't think through the details, but these kind of scenarios are
general the really "fun" gem bugs that bite hard 2 years later. Typing an
igt to repro your scenario and just check whether there's a problem would
be great. Worst case it's a good exercise in what kind of tricks are
needed to pull the kernel over the table.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2016-05-02  8:59 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-28 16:26 [PATCH 1/2] drm/i915: introduce & use i915_gem_object_mark_dirty() Dave Gordon
2016-04-28 16:26 ` [PATCH 2/2] drm/i915: a couple more uses for i915_gem_object_mark_dirty() Dave Gordon
2016-04-28 16:36   ` Chris Wilson
2016-04-28 17:20     ` Dave Gordon
2016-04-28 17:27       ` Chris Wilson
2016-04-28 16:34 ` [PATCH 1/2] drm/i915: introduce & use i915_gem_object_mark_dirty() Chris Wilson
2016-04-28 17:32   ` Dave Gordon
2016-04-28 17:48 ` ✗ Fi.CI.BAT: warning for series starting with [1/2] " Patchwork
2016-04-28 18:36   ` Dave Gordon
2016-05-02  8:58     ` Daniel Vetter

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.