* [PATCH] drm/i915: Recreate vmapping even when the object is pinned
@ 2017-08-26 13:39 Chris Wilson
2017-08-26 13:58 ` ✓ Fi.CI.BAT: success for " Patchwork
` (4 more replies)
0 siblings, 5 replies; 8+ messages in thread
From: Chris Wilson @ 2017-08-26 13:39 UTC (permalink / raw)
To: intel-gfx
Sometimes we know we are the only user of the bo, but since we take a
protective pin_pages early on, an attempt to change the vmap on the
object is denied because it is busy. i915_gem_object_pin_map() cannot
tell from our single pin_count if the operation is safe. Instead we must
pass that information down from the caller in the manner of
I915_MAP_OVERRIDE.
This issue has existed from the introduction of the mapping, but was
never noticed as the only place where this conflict might happen is for
cached kernel buffers (such as allocated by i915_gem_batch_pool_get()).
Until recently there was only a single user (the cmdparser) so no
conflicts ever occurred. However, we now use it to allocate batches for
different operations (using MAP_WC on !llc for writes) in addition to the
existing shadow batch (using MAP_WB for reads).
We could either keep both mappings cached, or use a different write
mechanism if we detect a MAP_WB already exists (i.e. clflush
afterwards), but as we haven't seen this issue in the wild (it requires
hitting the GPU reloc path in addition to the cmdparser) for simplicity
just allow the mappings to be recreated.
Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processing")
Testcase: igt/gem_lut_handle # byt, completely by accident
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 4 +++-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 ++-
4 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c
index f0cb22cc0dd6..c3ecd09d385c 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1073,7 +1073,7 @@ static u32 *copy_batch(struct drm_i915_gem_object *dst_obj,
goto unpin_src;
}
- dst = i915_gem_object_pin_map(dst_obj, I915_MAP_WB);
+ dst = i915_gem_object_pin_map(dst_obj, I915_MAP_WB | I915_MAP_OVERRIDE);
if (IS_ERR(dst))
goto unpin_dst;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8352cbe0c444..06f3500f157c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3485,6 +3485,7 @@ void __i915_gem_object_invalidate(struct drm_i915_gem_object *obj);
enum i915_map_type {
I915_MAP_WB = 0,
I915_MAP_WC,
+#define I915_MAP_OVERRIDE BIT(31)
};
/**
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 37fbc64d9ffe..3cd89bfceef0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2583,7 +2583,9 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
if (ret)
return ERR_PTR(ret);
- pinned = true;
+ pinned = !(type & I915_MAP_OVERRIDE);
+ type &= ~I915_MAP_OVERRIDE;
+
if (!atomic_inc_not_zero(&obj->mm.pages_pin_count)) {
if (unlikely(IS_ERR_OR_NULL(obj->mm.pages))) {
ret = ____i915_gem_object_get_pages(obj);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1c4fac032329..c3b564b97993 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1071,7 +1071,8 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
return PTR_ERR(obj);
cmd = i915_gem_object_pin_map(obj,
- cache->has_llc ? I915_MAP_WB : I915_MAP_WC);
+ (cache->has_llc ? I915_MAP_WB : I915_MAP_WC) |
+ I915_MAP_OVERRIDE);
i915_gem_object_unpin_pages(obj);
if (IS_ERR(cmd))
return PTR_ERR(cmd);
--
2.14.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 8+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915: Recreate vmapping even when the object is pinned
2017-08-26 13:39 [PATCH] drm/i915: Recreate vmapping even when the object is pinned Chris Wilson
@ 2017-08-26 13:58 ` Patchwork
2017-08-26 14:52 ` ✓ Fi.CI.IGT: " Patchwork
` (3 subsequent siblings)
4 siblings, 0 replies; 8+ messages in thread
From: Patchwork @ 2017-08-26 13:58 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Recreate vmapping even when the object is pinned
URL : https://patchwork.freedesktop.org/series/29388/
State : success
== Summary ==
Series 29388v1 drm/i915: Recreate vmapping even when the object is pinned
https://patchwork.freedesktop.org/api/1.0/series/29388/revisions/1/mbox/
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass -> FAIL (fi-snb-2600) fdo#100007
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
fail -> PASS (fi-snb-2600) fdo#100215
Test kms_flip:
Subgroup basic-flip-vs-modeset:
skip -> PASS (fi-skl-x1585l) fdo#101781
fdo#100007 https://bugs.freedesktop.org/show_bug.cgi?id=100007
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781
fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:454s
fi-bdw-gvtdvm total:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:443s
fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:369s
fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:544s
fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:251s
fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:522s
fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:515s
fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:513s
fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:438s
fi-glk-2a total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:610s
fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:462s
fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:422s
fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:423s
fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:501s
fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:475s
fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s
fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:600s
fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:595s
fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:524s
fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:464s
fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:480s
fi-skl-6770hq total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:494s
fi-skl-gvtdvm total:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:442s
fi-skl-x1585l total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:505s
fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:545s
fi-snb-2600 total:279 pass:248 dwarn:0 dfail:0 fail:2 skip:29 time:404s
c52f5322612a688655751c4dd44baa43e39d4dec drm-tip: 2017y-08m-26d-11h-41m-06s UTC integration manifest
744486525836 drm/i915: Recreate vmapping even when the object is pinned
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5500/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
* ✓ Fi.CI.IGT: success for drm/i915: Recreate vmapping even when the object is pinned
2017-08-26 13:39 [PATCH] drm/i915: Recreate vmapping even when the object is pinned Chris Wilson
2017-08-26 13:58 ` ✓ Fi.CI.BAT: success for " Patchwork
@ 2017-08-26 14:52 ` Patchwork
2017-08-28 10:46 ` [PATCH v2] " Chris Wilson
` (2 subsequent siblings)
4 siblings, 0 replies; 8+ messages in thread
From: Patchwork @ 2017-08-26 14:52 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Recreate vmapping even when the object is pinned
URL : https://patchwork.freedesktop.org/series/29388/
State : success
== Summary ==
Test perf:
Subgroup blocking:
pass -> FAIL (shard-hsw) fdo#102252 +1
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
shard-hsw total:2230 pass:1231 dwarn:0 dfail:0 fail:18 skip:981 time:9626s
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5500/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2] drm/i915: Recreate vmapping even when the object is pinned
2017-08-26 13:39 [PATCH] drm/i915: Recreate vmapping even when the object is pinned Chris Wilson
2017-08-26 13:58 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-08-26 14:52 ` ✓ Fi.CI.IGT: " Patchwork
@ 2017-08-28 10:46 ` Chris Wilson
2017-08-28 13:44 ` Joonas Lahtinen
2017-08-28 11:47 ` ✓ Fi.CI.BAT: success for drm/i915: Recreate vmapping even when the object is pinned (rev2) Patchwork
2017-08-28 13:53 ` ✓ Fi.CI.IGT: " Patchwork
4 siblings, 1 reply; 8+ messages in thread
From: Chris Wilson @ 2017-08-28 10:46 UTC (permalink / raw)
To: intel-gfx
Sometimes we know we are the only user of the bo, but since we take a
protective pin_pages early on, an attempt to change the vmap on the
object is denied because it is busy. i915_gem_object_pin_map() cannot
tell from our single pin_count if the operation is safe. Instead we must
pass that information down from the caller in the manner of
I915_MAP_OVERRIDE.
This issue has existed from the introduction of the mapping, but was
never noticed as the only place where this conflict might happen is for
cached kernel buffers (such as allocated by i915_gem_batch_pool_get()).
Until recently there was only a single user (the cmdparser) so no
conflicts ever occurred. However, we now use it to allocate batches for
different operations (using MAP_WC on !llc for writes) in addition to the
existing shadow batch (using MAP_WB for reads).
We could either keep both mappings cached, or use a different write
mechanism if we detect a MAP_WB already exists (i.e. clflush
afterwards), but as we haven't seen this issue in the wild (it requires
hitting the GPU reloc path in addition to the cmdparser) for simplicity
just allow the mappings to be recreated.
v2: Include the i915_MAP_OVERRIDE bit in the enum so the compiler knows
about all the valid values.
Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processing")
Testcase: igt/gem_lut_handle # byt, completely by accident
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_gem.c | 7 ++++++-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +++-
4 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c
index f0cb22cc0dd6..8ba932b22f7c 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1073,7 +1073,7 @@ static u32 *copy_batch(struct drm_i915_gem_object *dst_obj,
goto unpin_src;
}
- dst = i915_gem_object_pin_map(dst_obj, I915_MAP_WB);
+ dst = i915_gem_object_pin_map(dst_obj, I915_MAP_FORCE_WB);
if (IS_ERR(dst))
goto unpin_dst;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8352cbe0c444..0383e879a315 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3485,6 +3485,9 @@ void __i915_gem_object_invalidate(struct drm_i915_gem_object *obj);
enum i915_map_type {
I915_MAP_WB = 0,
I915_MAP_WC,
+#define I915_MAP_OVERRIDE BIT(31)
+ I915_MAP_FORCE_WB = I915_MAP_WB | I915_MAP_OVERRIDE,
+ I915_MAP_FORCE_WC = I915_MAP_WC | I915_MAP_OVERRIDE,
};
/**
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 37fbc64d9ffe..43834dee4e8d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2553,6 +2553,9 @@ static void *i915_gem_object_map(const struct drm_i915_gem_object *obj,
GEM_BUG_ON(i != n_pages);
switch (type) {
+ default:
+ MISSING_CASE(type);
+ /* fallthrough to use PAGE_KERNEL anyway */
case I915_MAP_WB:
pgprot = PAGE_KERNEL;
break;
@@ -2583,7 +2586,9 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
if (ret)
return ERR_PTR(ret);
- pinned = true;
+ pinned = !(type & I915_MAP_OVERRIDE);
+ type &= ~I915_MAP_OVERRIDE;
+
if (!atomic_inc_not_zero(&obj->mm.pages_pin_count)) {
if (unlikely(IS_ERR_OR_NULL(obj->mm.pages))) {
ret = ____i915_gem_object_get_pages(obj);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1c4fac032329..dcce69a23309 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1071,7 +1071,9 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
return PTR_ERR(obj);
cmd = i915_gem_object_pin_map(obj,
- cache->has_llc ? I915_MAP_WB : I915_MAP_WC);
+ cache->has_llc ?
+ I915_MAP_FORCE_WB :
+ I915_MAP_FORCE_WC);
i915_gem_object_unpin_pages(obj);
if (IS_ERR(cmd))
return PTR_ERR(cmd);
--
2.14.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 8+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915: Recreate vmapping even when the object is pinned (rev2)
2017-08-26 13:39 [PATCH] drm/i915: Recreate vmapping even when the object is pinned Chris Wilson
` (2 preceding siblings ...)
2017-08-28 10:46 ` [PATCH v2] " Chris Wilson
@ 2017-08-28 11:47 ` Patchwork
2017-08-28 13:53 ` ✓ Fi.CI.IGT: " Patchwork
4 siblings, 0 replies; 8+ messages in thread
From: Patchwork @ 2017-08-28 11:47 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Recreate vmapping even when the object is pinned (rev2)
URL : https://patchwork.freedesktop.org/series/29388/
State : success
== Summary ==
Series 29388v2 drm/i915: Recreate vmapping even when the object is pinned
https://patchwork.freedesktop.org/api/1.0/series/29388/revisions/2/mbox/
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
fail -> PASS (fi-snb-2600) fdo#100215
Subgroup basic-flip-after-cursor-varying-size:
pass -> FAIL (fi-hsw-4770) fdo#102402 +1
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass -> SKIP (fi-skl-x1585l) fdo#101781
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#102402 https://bugs.freedesktop.org/show_bug.cgi?id=102402
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781
fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:458s
fi-bdw-gvtdvm total:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:437s
fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:361s
fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:554s
fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:253s
fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:512s
fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:520s
fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:515s
fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:436s
fi-glk-2a total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:610s
fi-hsw-4770 total:279 pass:261 dwarn:0 dfail:0 fail:2 skip:16 time:464s
fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:427s
fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:421s
fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:506s
fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:471s
fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:475s
fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:603s
fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:598s
fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:526s
fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:468s
fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s
fi-skl-6770hq total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:487s
fi-skl-gvtdvm total:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:438s
fi-skl-x1585l total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:487s
fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:547s
fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:406s
00b77f621f835bc114b79ec897b9aa277ea5726b drm-tip: 2017y-08m-28d-10h-25m-08s UTC integration manifest
1dad816b4277 drm/i915: Recreate vmapping even when the object is pinned
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5507/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] drm/i915: Recreate vmapping even when the object is pinned
2017-08-28 10:46 ` [PATCH v2] " Chris Wilson
@ 2017-08-28 13:44 ` Joonas Lahtinen
2017-08-29 10:00 ` Chris Wilson
0 siblings, 1 reply; 8+ messages in thread
From: Joonas Lahtinen @ 2017-08-28 13:44 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
On Mon, 2017-08-28 at 11:46 +0100, Chris Wilson wrote:
> Sometimes we know we are the only user of the bo, but since we take a
> protective pin_pages early on, an attempt to change the vmap on the
> object is denied because it is busy. i915_gem_object_pin_map() cannot
> tell from our single pin_count if the operation is safe. Instead we must
> pass that information down from the caller in the manner of
> I915_MAP_OVERRIDE.
>
> This issue has existed from the introduction of the mapping, but was
> never noticed as the only place where this conflict might happen is for
> cached kernel buffers (such as allocated by i915_gem_batch_pool_get()).
> Until recently there was only a single user (the cmdparser) so no
> conflicts ever occurred. However, we now use it to allocate batches for
> different operations (using MAP_WC on !llc for writes) in addition to the
> existing shadow batch (using MAP_WB for reads).
>
> We could either keep both mappings cached, or use a different write
> mechanism if we detect a MAP_WB already exists (i.e. clflush
> afterwards), but as we haven't seen this issue in the wild (it requires
> hitting the GPU reloc path in addition to the cmdparser) for simplicity
> just allow the mappings to be recreated.
>
> v2: Include the i915_MAP_OVERRIDE bit in the enum so the compiler knows
> about all the valid values.
>
> Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processing")
> Testcase: igt/gem_lut_handle # byt, completely by accident
> 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] 8+ messages in thread
* ✓ Fi.CI.IGT: success for drm/i915: Recreate vmapping even when the object is pinned (rev2)
2017-08-26 13:39 [PATCH] drm/i915: Recreate vmapping even when the object is pinned Chris Wilson
` (3 preceding siblings ...)
2017-08-28 11:47 ` ✓ Fi.CI.BAT: success for drm/i915: Recreate vmapping even when the object is pinned (rev2) Patchwork
@ 2017-08-28 13:53 ` Patchwork
4 siblings, 0 replies; 8+ messages in thread
From: Patchwork @ 2017-08-28 13:53 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Recreate vmapping even when the object is pinned (rev2)
URL : https://patchwork.freedesktop.org/series/29388/
State : success
== Summary ==
shard-hsw total:2230 pass:1232 dwarn:0 dfail:0 fail:16 skip:982 time:9615s
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5507/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] drm/i915: Recreate vmapping even when the object is pinned
2017-08-28 13:44 ` Joonas Lahtinen
@ 2017-08-29 10:00 ` Chris Wilson
0 siblings, 0 replies; 8+ messages in thread
From: Chris Wilson @ 2017-08-29 10:00 UTC (permalink / raw)
To: Joonas Lahtinen, intel-gfx
Quoting Joonas Lahtinen (2017-08-28 14:44:36)
> On Mon, 2017-08-28 at 11:46 +0100, Chris Wilson wrote:
> > Sometimes we know we are the only user of the bo, but since we take a
> > protective pin_pages early on, an attempt to change the vmap on the
> > object is denied because it is busy. i915_gem_object_pin_map() cannot
> > tell from our single pin_count if the operation is safe. Instead we must
> > pass that information down from the caller in the manner of
> > I915_MAP_OVERRIDE.
> >
> > This issue has existed from the introduction of the mapping, but was
> > never noticed as the only place where this conflict might happen is for
> > cached kernel buffers (such as allocated by i915_gem_batch_pool_get()).
> > Until recently there was only a single user (the cmdparser) so no
> > conflicts ever occurred. However, we now use it to allocate batches for
> > different operations (using MAP_WC on !llc for writes) in addition to the
> > existing shadow batch (using MAP_WB for reads).
> >
> > We could either keep both mappings cached, or use a different write
> > mechanism if we detect a MAP_WB already exists (i.e. clflush
> > afterwards), but as we haven't seen this issue in the wild (it requires
> > hitting the GPU reloc path in addition to the cmdparser) for simplicity
> > just allow the mappings to be recreated.
> >
> > v2: Include the i915_MAP_OVERRIDE bit in the enum so the compiler knows
> > about all the valid values.
> >
> > Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processing")
> > Testcase: igt/gem_lut_handle # byt, completely by accident
> > 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>
And pushed. Only afterwards when looking for the link did I notice I
forgot to mention the bugzilla.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-08-29 10:00 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-26 13:39 [PATCH] drm/i915: Recreate vmapping even when the object is pinned Chris Wilson
2017-08-26 13:58 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-08-26 14:52 ` ✓ Fi.CI.IGT: " Patchwork
2017-08-28 10:46 ` [PATCH v2] " Chris Wilson
2017-08-28 13:44 ` Joonas Lahtinen
2017-08-29 10:00 ` Chris Wilson
2017-08-28 11:47 ` ✓ Fi.CI.BAT: success for drm/i915: Recreate vmapping even when the object is pinned (rev2) Patchwork
2017-08-28 13:53 ` ✓ Fi.CI.IGT: " Patchwork
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.