* [resend] drm/i915: Check incoming alignment for unfenced buffers (on i915gm)
@ 2017-10-31 10:36 Chris Wilson
2017-10-31 11:11 ` ✓ Fi.CI.BAT: success for drm/i915: Check incoming alignment for unfenced buffers (on i915gm) (rev2) Patchwork
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Chris Wilson @ 2017-10-31 10:36 UTC (permalink / raw)
To: intel-gfx
In case the object has changed tiling between calls to execbuf, we need
to check if the existing offset inside the GTT matches the new tiling
constraint. We even need to do this for "unfenced" tiled objects, where
the 3D commands use an implied fence and so the object still needs to
match the physical fence restrictions on alignment (only required for
gen2 and early gen3).
In commit 2889caa92321 ("drm/i915: Eliminate lots of iterations over
the execobjects array"), the idea was to remove the second guessing and
only set the NEEDS_MAP flag when required. However, the entire check
for an unusable offset for fencing was removed and not just the
secondary check. I.e.
/* avoid costly ping-pong once a batch bo ended up non-mappable */
if (entry->flags & __EXEC_OBJECT_NEEDS_MAP &&
!i915_vma_is_map_and_fenceable(vma))
return !only_mappable_for_reloc(entry->flags);
was entirely removed as the ping-pong between execbuf passes was fixed,
but its primary purpose in forcing unaligned unfenced access to be
rebound was forgotten.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103502
Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 3d7190764f10..5b8213b1a8c7 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -343,6 +343,10 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2 *entry,
(vma->node.start + vma->node.size - 1) >> 32)
return true;
+ if (flags & __EXEC_OBJECT_NEEDS_MAP &&
+ !i915_vma_is_map_and_fenceable(vma))
+ return true;
+
return false;
}
--
2.15.0.rc2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 5+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915: Check incoming alignment for unfenced buffers (on i915gm) (rev2)
2017-10-31 10:36 [resend] drm/i915: Check incoming alignment for unfenced buffers (on i915gm) Chris Wilson
@ 2017-10-31 11:11 ` Patchwork
2017-10-31 12:27 ` ✗ Fi.CI.IGT: warning " Patchwork
2017-11-01 13:17 ` [resend] drm/i915: Check incoming alignment for unfenced buffers (on i915gm) Joonas Lahtinen
2 siblings, 0 replies; 5+ messages in thread
From: Patchwork @ 2017-10-31 11:11 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Check incoming alignment for unfenced buffers (on i915gm) (rev2)
URL : https://patchwork.freedesktop.org/series/32828/
State : success
== Summary ==
Series 32828v2 drm/i915: Check incoming alignment for unfenced buffers (on i915gm)
https://patchwork.freedesktop.org/api/1.0/series/32828/revisions/2/mbox/
Test pm_rpm:
Subgroup basic-rte:
skip -> PASS (fi-hsw-4770r) fdo#103522
Test drv_module_reload:
Subgroup basic-reload-inject:
incomplete -> DMESG-WARN (fi-cfl-s) fdo#103206
fdo#103522 https://bugs.freedesktop.org/show_bug.cgi?id=103522
fdo#103206 https://bugs.freedesktop.org/show_bug.cgi?id=103206
fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:436s
fi-bdw-gvtdvm total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:450s
fi-blb-e6850 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:374s
fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:526s
fi-bwr-2160 total:289 pass:183 dwarn:0 dfail:0 fail:0 skip:106 time:265s
fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:501s
fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:500s
fi-byt-j1900 total:289 pass:253 dwarn:1 dfail:0 fail:0 skip:35 time:492s
fi-byt-n2820 total:289 pass:249 dwarn:1 dfail:0 fail:0 skip:39 time:481s
fi-cfl-s total:289 pass:253 dwarn:4 dfail:0 fail:0 skip:32 time:552s
fi-cnl-y total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:610s
fi-elk-e7500 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:423s
fi-gdg-551 total:289 pass:178 dwarn:1 dfail:0 fail:1 skip:109 time:247s
fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:585s
fi-glk-dsi total:289 pass:258 dwarn:0 dfail:0 fail:1 skip:30 time:489s
fi-hsw-4770 total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:432s
fi-hsw-4770r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:426s
fi-ilk-650 total:289 pass:228 dwarn:0 dfail:0 fail:0 skip:61 time:419s
fi-ivb-3520m total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:506s
fi-ivb-3770 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:460s
fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:488s
fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:567s
fi-kbl-7567u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:476s
fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:581s
fi-pnv-d510 total:289 pass:222 dwarn:1 dfail:0 fail:0 skip:66 time:558s
fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:455s
fi-skl-6600u total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:591s
fi-skl-6700hq total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:651s
fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:529s
fi-skl-6770hq total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:498s
fi-skl-gvtdvm total:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:458s
fi-snb-2520m total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:554s
fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:415s
dfe1410689e638c987b39e07288bc1951cb252f3 drm-tip: 2017y-10m-31d-09h-42m-59s UTC integration manifest
58f8a5b2b374 drm/i915: Check incoming alignment for unfenced buffers (on i915gm)
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6275/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 5+ messages in thread
* ✗ Fi.CI.IGT: warning for drm/i915: Check incoming alignment for unfenced buffers (on i915gm) (rev2)
2017-10-31 10:36 [resend] drm/i915: Check incoming alignment for unfenced buffers (on i915gm) Chris Wilson
2017-10-31 11:11 ` ✓ Fi.CI.BAT: success for drm/i915: Check incoming alignment for unfenced buffers (on i915gm) (rev2) Patchwork
@ 2017-10-31 12:27 ` Patchwork
2017-11-01 13:17 ` [resend] drm/i915: Check incoming alignment for unfenced buffers (on i915gm) Joonas Lahtinen
2 siblings, 0 replies; 5+ messages in thread
From: Patchwork @ 2017-10-31 12:27 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Check incoming alignment for unfenced buffers (on i915gm) (rev2)
URL : https://patchwork.freedesktop.org/series/32828/
State : warning
== Summary ==
Test kms_flip:
Subgroup vblank-vs-dpms-suspend:
pass -> SKIP (shard-hsw)
Subgroup flip-vs-expired-vblank-interruptible:
pass -> FAIL (shard-hsw) fdo#102887
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-legacy:
pass -> FAIL (shard-hsw) fdo#102670
Test perf:
Subgroup polling:
pass -> FAIL (shard-hsw) fdo#102252
Test kms_frontbuffer_tracking:
Subgroup fbc-modesetfrombusy:
pass -> SKIP (shard-hsw)
Test drv_module_reload:
Subgroup basic-reload:
pass -> DMESG-WARN (shard-hsw) fdo#102707
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
shard-hsw total:2539 pass:1427 dwarn:2 dfail:0 fail:11 skip:1099 time:9398s
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6275/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [resend] drm/i915: Check incoming alignment for unfenced buffers (on i915gm)
2017-10-31 10:36 [resend] drm/i915: Check incoming alignment for unfenced buffers (on i915gm) Chris Wilson
2017-10-31 11:11 ` ✓ Fi.CI.BAT: success for drm/i915: Check incoming alignment for unfenced buffers (on i915gm) (rev2) Patchwork
2017-10-31 12:27 ` ✗ Fi.CI.IGT: warning " Patchwork
@ 2017-11-01 13:17 ` Joonas Lahtinen
2017-11-01 13:46 ` Chris Wilson
2 siblings, 1 reply; 5+ messages in thread
From: Joonas Lahtinen @ 2017-11-01 13:17 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
On Tue, 2017-10-31 at 10:36 +0000, Chris Wilson wrote:
> In case the object has changed tiling between calls to execbuf, we need
> to check if the existing offset inside the GTT matches the new tiling
> constraint. We even need to do this for "unfenced" tiled objects, where
> the 3D commands use an implied fence and so the object still needs to
> match the physical fence restrictions on alignment (only required for
> gen2 and early gen3).
>
> In commit 2889caa92321 ("drm/i915: Eliminate lots of iterations over
> the execobjects array"), the idea was to remove the second guessing and
> only set the NEEDS_MAP flag when required. However, the entire check
> for an unusable offset for fencing was removed and not just the
> secondary check. I.e.
>
> /* avoid costly ping-pong once a batch bo ended up non-mappable */
> if (entry->flags & __EXEC_OBJECT_NEEDS_MAP &&
> !i915_vma_is_map_and_fenceable(vma))
> return !only_mappable_for_reloc(entry->flags);
>
> was entirely removed as the ping-pong between execbuf passes was fixed,
> but its primary purpose in forcing unaligned unfenced access to be
> rebound was forgotten.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103502
> Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [resend] drm/i915: Check incoming alignment for unfenced buffers (on i915gm)
2017-11-01 13:17 ` [resend] drm/i915: Check incoming alignment for unfenced buffers (on i915gm) Joonas Lahtinen
@ 2017-11-01 13:46 ` Chris Wilson
0 siblings, 0 replies; 5+ messages in thread
From: Chris Wilson @ 2017-11-01 13:46 UTC (permalink / raw)
To: Joonas Lahtinen, intel-gfx
Quoting Joonas Lahtinen (2017-11-01 13:17:11)
> On Tue, 2017-10-31 at 10:36 +0000, Chris Wilson wrote:
> > In case the object has changed tiling between calls to execbuf, we need
> > to check if the existing offset inside the GTT matches the new tiling
> > constraint. We even need to do this for "unfenced" tiled objects, where
> > the 3D commands use an implied fence and so the object still needs to
> > match the physical fence restrictions on alignment (only required for
> > gen2 and early gen3).
> >
> > In commit 2889caa92321 ("drm/i915: Eliminate lots of iterations over
> > the execobjects array"), the idea was to remove the second guessing and
> > only set the NEEDS_MAP flag when required. However, the entire check
> > for an unusable offset for fencing was removed and not just the
> > secondary check. I.e.
> >
> > /* avoid costly ping-pong once a batch bo ended up non-mappable */
> > if (entry->flags & __EXEC_OBJECT_NEEDS_MAP &&
> > !i915_vma_is_map_and_fenceable(vma))
> > return !only_mappable_for_reloc(entry->flags);
> >
> > was entirely removed as the ping-pong between execbuf passes was fixed,
> > but its primary purpose in forcing unaligned unfenced access to be
> > rebound was forgotten.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103502
> > Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array")
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>
> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Ta. So I'd been pondering how to catch this in CI. In theory, this could
be caught by gem_render_tiled_blit, but it firstly requires checking
that the rendercopy routines use the implicit fence instructions and
secondary we need lots of repetitions with interleaved set-tiling to try
and cause an address conflict. And then we have only one machine in the
farm that is even susceptible to this bug...
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-11-01 13:46 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-31 10:36 [resend] drm/i915: Check incoming alignment for unfenced buffers (on i915gm) Chris Wilson
2017-10-31 11:11 ` ✓ Fi.CI.BAT: success for drm/i915: Check incoming alignment for unfenced buffers (on i915gm) (rev2) Patchwork
2017-10-31 12:27 ` ✗ Fi.CI.IGT: warning " Patchwork
2017-11-01 13:17 ` [resend] drm/i915: Check incoming alignment for unfenced buffers (on i915gm) Joonas Lahtinen
2017-11-01 13:46 ` Chris Wilson
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.