* [PATCH 1/2] drm/i915: Unconditionally flush any chipset buffers before execbuf
@ 2016-08-18 13:12 ` Chris Wilson
0 siblings, 0 replies; 10+ messages in thread
From: Chris Wilson @ 2016-08-18 13:12 UTC (permalink / raw)
To: intel-gfx
Cc: mika.kuoppala, Chris Wilson, Akash Goel, Daniel Vetter,
Tvrtko Ursulin, stable
If userspace is asynchronously streaming into the batch or other
execobjects, we may not flush those writes along with a change in cache
domain (as there is no change). Therefore those writes may end up in
internal chipset buffers and not visible to the GPU upon execution. We
must issue a flush command or otherwise we encounter incoherency in the
batchbuffers and the GPU executing invalid commands (i.e. hanging) quite
regularly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90841
Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user...")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Akash Goel <akash.goel@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Tested-by: Matti Hämäläinen <ccr@tnsp.org>
Cc: stable@vger.kernel.org
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 699315304748..bce587abc601 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1015,8 +1015,6 @@ i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request *req,
{
const unsigned int other_rings = eb_other_engines(req);
struct i915_vma *vma;
- uint32_t flush_domains = 0;
- bool flush_chipset = false;
int ret;
list_for_each_entry(vma, vmas, exec_list) {
@@ -1029,16 +1027,11 @@ i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request *req,
}
if (obj->base.write_domain & I915_GEM_DOMAIN_CPU)
- flush_chipset |= i915_gem_clflush_object(obj, false);
-
- flush_domains |= obj->base.write_domain;
+ i915_gem_clflush_object(obj, false);
}
- if (flush_chipset)
- i915_gem_chipset_flush(req->engine->i915);
-
- if (flush_domains & I915_GEM_DOMAIN_GTT)
- wmb();
+ /* Unconditionally flush any chipset caches (for streaming writes). */
+ i915_gem_chipset_flush(req->engine->i915);
/* Unconditionally invalidate GPU caches and TLBs. */
return req->engine->emit_flush(req, EMIT_INVALIDATE);
--
2.9.3
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH 1/2] drm/i915: Unconditionally flush any chipset buffers before execbuf
@ 2016-08-18 13:12 ` Chris Wilson
0 siblings, 0 replies; 10+ messages in thread
From: Chris Wilson @ 2016-08-18 13:12 UTC (permalink / raw)
To: intel-gfx; +Cc: Daniel Vetter, stable, Akash Goel, mika.kuoppala
If userspace is asynchronously streaming into the batch or other
execobjects, we may not flush those writes along with a change in cache
domain (as there is no change). Therefore those writes may end up in
internal chipset buffers and not visible to the GPU upon execution. We
must issue a flush command or otherwise we encounter incoherency in the
batchbuffers and the GPU executing invalid commands (i.e. hanging) quite
regularly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90841
Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user...")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Akash Goel <akash.goel@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Tested-by: Matti Hämäläinen <ccr@tnsp.org>
Cc: stable@vger.kernel.org
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 699315304748..bce587abc601 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1015,8 +1015,6 @@ i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request *req,
{
const unsigned int other_rings = eb_other_engines(req);
struct i915_vma *vma;
- uint32_t flush_domains = 0;
- bool flush_chipset = false;
int ret;
list_for_each_entry(vma, vmas, exec_list) {
@@ -1029,16 +1027,11 @@ i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request *req,
}
if (obj->base.write_domain & I915_GEM_DOMAIN_CPU)
- flush_chipset |= i915_gem_clflush_object(obj, false);
-
- flush_domains |= obj->base.write_domain;
+ i915_gem_clflush_object(obj, false);
}
- if (flush_chipset)
- i915_gem_chipset_flush(req->engine->i915);
-
- if (flush_domains & I915_GEM_DOMAIN_GTT)
- wmb();
+ /* Unconditionally flush any chipset caches (for streaming writes). */
+ i915_gem_chipset_flush(req->engine->i915);
/* Unconditionally invalidate GPU caches and TLBs. */
return req->engine->emit_flush(req, EMIT_INVALIDATE);
--
2.9.3
_______________________________________________
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] agp/intel: Flush chipset writes after updating a single PTE
2016-08-18 13:12 ` Chris Wilson
(?)
@ 2016-08-18 13:12 ` Chris Wilson
2016-08-18 15:18 ` Mika Kuoppala
-1 siblings, 1 reply; 10+ messages in thread
From: Chris Wilson @ 2016-08-18 13:12 UTC (permalink / raw)
To: intel-gfx; +Cc: Ankitprasad Sharma, drm-intel-fixes, mika.kuoppala
After we update one PTE for a page, the caller expects to be able to
immediately use that through a GGTT read/write. To comply with the
callers expectations we therefore need to flush the chipset buffers
before returning.
Reported-by: Matti Hämäläinen <ccr@tnsp.org>
Fixes: d6473f566417 ("drm/i915: Add support for mapping an object page...")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Tested-by: Matti Hämäläinen <ccr@tnsp.org>
Cc: drm-intel-fixes@lists.freedesktop.org
---
drivers/char/agp/intel-gtt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 44311296ec02..0f7d28a98b9a 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -845,6 +845,8 @@ void intel_gtt_insert_page(dma_addr_t addr,
unsigned int flags)
{
intel_private.driver->write_entry(addr, pg, flags);
+ if (intel_private.driver->chipset_flush)
+ intel_private.driver->chipset_flush();
}
EXPORT_SYMBOL(intel_gtt_insert_page);
--
2.9.3
_______________________________________________
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 v2] drm/i915: Fallback to single page pwrite/pread if unable to release fence
2016-08-18 13:12 ` Chris Wilson
(?)
(?)
@ 2016-08-18 13:33 ` Chris Wilson
-1 siblings, 0 replies; 10+ messages in thread
From: Chris Wilson @ 2016-08-18 13:33 UTC (permalink / raw)
To: intel-gfx
If we cannot release the fence (for example if someone is inexplicably
trying to write into a tiled framebuffer that is currently pinned to the
display! *cough* kms_frontbuffer_tracking *cough*) fallback to using the
page-by-page pwrite/pread interface, rather than fail the syscall
entirely.
Since this is triggerable by the user (along pwrite) we have to remove
the WARN_ON(fence->pin_count).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
drivers/gpu/drm/i915/i915_gem.c | 30 ++++++++++++++++++------------
drivers/gpu/drm/i915/i915_gem_fence.c | 2 +-
2 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cb75beb7f352..6d64ee34efc6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -754,6 +754,15 @@ i915_gem_gtt_pread(struct drm_device *dev,
int ret;
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, PIN_MAPPABLE);
+ if (!IS_ERR(vma)) {
+ node.start = i915_ggtt_offset(vma);
+ node.allocated = false;
+ ret = i915_gem_object_put_fence(obj);
+ if (ret) {
+ i915_vma_unpin(vma);
+ vma = ERR_PTR(ret);
+ }
+ }
if (IS_ERR(vma)) {
ret = insert_mappable_node(dev_priv, &node, PAGE_SIZE);
if (ret)
@@ -766,12 +775,6 @@ i915_gem_gtt_pread(struct drm_device *dev,
}
i915_gem_object_pin_pages(obj);
- } else {
- node.start = i915_ggtt_offset(vma);
- node.allocated = false;
- ret = i915_gem_object_put_fence(obj);
- if (ret)
- goto out_unpin;
}
ret = i915_gem_object_set_to_gtt_domain(obj, false);
@@ -1058,6 +1061,15 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
PIN_MAPPABLE | PIN_NONBLOCK);
+ if (!IS_ERR(vma)) {
+ node.start = i915_ggtt_offset(vma);
+ node.allocated = false;
+ ret = i915_gem_object_put_fence(obj);
+ if (ret) {
+ i915_vma_unpin(vma);
+ vma = ERR_PTR(ret);
+ }
+ }
if (IS_ERR(vma)) {
ret = insert_mappable_node(i915, &node, PAGE_SIZE);
if (ret)
@@ -1070,12 +1082,6 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
}
i915_gem_object_pin_pages(obj);
- } else {
- node.start = i915_ggtt_offset(vma);
- node.allocated = false;
- ret = i915_gem_object_put_fence(obj);
- if (ret)
- goto out_unpin;
}
ret = i915_gem_object_set_to_gtt_domain(obj, true);
diff --git a/drivers/gpu/drm/i915/i915_gem_fence.c b/drivers/gpu/drm/i915/i915_gem_fence.c
index 334c3c4e8357..b0c6c2777725 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence.c
@@ -298,7 +298,7 @@ i915_gem_object_put_fence(struct drm_i915_gem_object *obj)
fence = &dev_priv->fence_regs[obj->fence_reg];
- if (WARN_ON(fence->pin_count))
+ if (fence->pin_count)
return -EBUSY;
i915_gem_object_fence_lost(obj);
--
2.9.3
_______________________________________________
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
* ✓ Ro.CI.BAT: success for series starting with [1/2] drm/i915: Unconditionally flush any chipset buffers before execbuf
2016-08-18 13:12 ` Chris Wilson
` (2 preceding siblings ...)
(?)
@ 2016-08-18 13:52 ` Patchwork
-1 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2016-08-18 13:52 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: series starting with [1/2] drm/i915: Unconditionally flush any chipset buffers before execbuf
URL : https://patchwork.freedesktop.org/series/11266/
State : success
== Summary ==
Series 11266v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/11266/revisions/1/mbox
Test kms_cursor_legacy:
Subgroup basic-flip-vs-cursor-varying-size:
fail -> PASS (ro-bdw-i5-5250u)
dmesg-fail -> PASS (fi-skl-i7-6700k)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> SKIP (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> SKIP (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS (ro-bdw-i7-5600u)
dmesg-warn -> SKIP (ro-bdw-i5-5250u)
fi-hsw-i7-4770k total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-kbl-qkkr total:244 pass:185 dwarn:29 dfail:0 fail:3 skip:27
fi-skl-i7-6700k total:244 pass:209 dwarn:4 dfail:1 fail:2 skip:28
fi-snb-i7-2600 total:244 pass:202 dwarn:0 dfail:0 fail:0 skip:42
ro-bdw-i5-5250u total:240 pass:220 dwarn:1 dfail:0 fail:0 skip:19
ro-bdw-i7-5600u total:240 pass:206 dwarn:1 dfail:0 fail:1 skip:32
ro-bsw-n3050 total:240 pass:195 dwarn:0 dfail:0 fail:3 skip:42
ro-byt-n2820 total:240 pass:197 dwarn:0 dfail:0 fail:3 skip:40
ro-hsw-i3-4010u total:240 pass:214 dwarn:0 dfail:0 fail:0 skip:26
ro-ilk1-i5-650 total:235 pass:174 dwarn:0 dfail:0 fail:1 skip:60
ro-ivb-i7-3770 total:240 pass:205 dwarn:0 dfail:0 fail:0 skip:35
ro-ivb2-i7-3770 total:240 pass:209 dwarn:0 dfail:0 fail:0 skip:31
ro-skl3-i5-6260u total:240 pass:222 dwarn:0 dfail:0 fail:4 skip:14
ro-bdw-i7-5557U failed to connect after reboot
Results at /archive/results/CI_IGT_test/RO_Patchwork_1928/
ee3f71b drm-intel-nightly: 2016y-08m-18d-12h-30m-08s UTC integration manifest
e36f7d5 agp/intel: Flush chipset writes after updating a single PTE
4fe257d drm/i915: Unconditionally flush any chipset buffers before execbuf
_______________________________________________
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: Unconditionally flush any chipset buffers before execbuf
2016-08-18 13:12 ` Chris Wilson
` (3 preceding siblings ...)
(?)
@ 2016-08-18 13:59 ` Mika Kuoppala
2016-08-18 14:31 ` Chris Wilson
-1 siblings, 1 reply; 10+ messages in thread
From: Mika Kuoppala @ 2016-08-18 13:59 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: Daniel Vetter, Akash Goel, stable
Chris Wilson <chris@chris-wilson.co.uk> writes:
> If userspace is asynchronously streaming into the batch or other
> execobjects, we may not flush those writes along with a change in cache
> domain (as there is no change). Therefore those writes may end up in
> internal chipset buffers and not visible to the GPU upon execution. We
> must issue a flush command or otherwise we encounter incoherency in the
> batchbuffers and the GPU executing invalid commands (i.e. hanging) quite
> regularly.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90841
> Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user...")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Akash Goel <akash.goel@intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Tested-by: Matti Hämäläinen <ccr@tnsp.org>
> Cc: stable@vger.kernel.org
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +++----------
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 699315304748..bce587abc601 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1015,8 +1015,6 @@ i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request *req,
> {
> const unsigned int other_rings = eb_other_engines(req);
> struct i915_vma *vma;
> - uint32_t flush_domains = 0;
> - bool flush_chipset = false;
> int ret;
>
> list_for_each_entry(vma, vmas, exec_list) {
> @@ -1029,16 +1027,11 @@ i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request *req,
> }
>
> if (obj->base.write_domain & I915_GEM_DOMAIN_CPU)
> - flush_chipset |= i915_gem_clflush_object(obj, false);
> -
> - flush_domains |= obj->base.write_domain;
> + i915_gem_clflush_object(obj, false);
> }
>
> - if (flush_chipset)
> - i915_gem_chipset_flush(req->engine->i915);
> -
> - if (flush_domains & I915_GEM_DOMAIN_GTT)
> - wmb();
Was a bit worried about this vanishing.
But after chatting with Chris and also founding this:
https://lwn.net/Articles/174655/
[in I386 AND X86_64 SPECIFIC NOTES]
I am convinced that the uncached write to force the chipset_flush
will be strong barrier enough.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
> + /* Unconditionally flush any chipset caches (for streaming writes). */
> + i915_gem_chipset_flush(req->engine->i915);
>
> /* Unconditionally invalidate GPU caches and TLBs. */
> return req->engine->emit_flush(req, EMIT_INVALIDATE);
> --
> 2.9.3
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
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
* ✗ Ro.CI.BAT: warning for series starting with [v2] drm/i915: Fallback to single page pwrite/pread if unable to release fence (rev2)
2016-08-18 13:12 ` Chris Wilson
` (4 preceding siblings ...)
(?)
@ 2016-08-18 14:18 ` Patchwork
-1 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2016-08-18 14:18 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: series starting with [v2] drm/i915: Fallback to single page pwrite/pread if unable to release fence (rev2)
URL : https://patchwork.freedesktop.org/series/11266/
State : warning
== Summary ==
Series 11266v2 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/11266/revisions/2/mbox
Test drv_module_reload_basic:
pass -> SKIP (ro-bdw-i5-5250u)
Test kms_cursor_legacy:
Subgroup basic-flip-vs-cursor-legacy:
fail -> PASS (ro-skl3-i5-6260u)
Subgroup basic-flip-vs-cursor-varying-size:
fail -> PASS (ro-skl3-i5-6260u)
dmesg-fail -> PASS (fi-skl-i7-6700k)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS (ro-bdw-i7-5600u)
dmesg-warn -> SKIP (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS (ro-bdw-i7-5600u)
fi-hsw-i7-4770k total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-kbl-qkkr total:244 pass:185 dwarn:30 dfail:0 fail:2 skip:27
fi-skl-i7-6700k total:244 pass:209 dwarn:4 dfail:1 fail:2 skip:28
fi-snb-i7-2600 total:244 pass:202 dwarn:0 dfail:0 fail:0 skip:42
ro-bdw-i5-5250u total:240 pass:218 dwarn:3 dfail:0 fail:1 skip:18
ro-bdw-i7-5600u total:240 pass:207 dwarn:0 dfail:0 fail:1 skip:32
ro-bsw-n3050 total:240 pass:193 dwarn:0 dfail:0 fail:4 skip:43
ro-byt-n2820 total:240 pass:197 dwarn:0 dfail:0 fail:3 skip:40
ro-hsw-i3-4010u total:240 pass:214 dwarn:0 dfail:0 fail:0 skip:26
ro-hsw-i7-4770r total:240 pass:185 dwarn:0 dfail:0 fail:0 skip:55
ro-ilk1-i5-650 total:235 pass:174 dwarn:0 dfail:0 fail:1 skip:60
ro-ivb-i7-3770 total:240 pass:205 dwarn:0 dfail:0 fail:0 skip:35
ro-ivb2-i7-3770 total:240 pass:209 dwarn:0 dfail:0 fail:0 skip:31
ro-skl3-i5-6260u total:240 pass:224 dwarn:0 dfail:0 fail:2 skip:14
ro-bdw-i7-5557U failed to connect after reboot
Results at /archive/results/CI_IGT_test/RO_Patchwork_1929/
ee3f71b drm-intel-nightly: 2016y-08m-18d-12h-30m-08s UTC integration manifest
3e4cac6 agp/intel: Flush chipset writes after updating a single PTE
b76d651 drm/i915: Fallback to single page pwrite/pread if unable to release fence
_______________________________________________
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: [Intel-gfx] [PATCH 1/2] drm/i915: Unconditionally flush any chipset buffers before execbuf
2016-08-18 13:59 ` [PATCH 1/2] " Mika Kuoppala
@ 2016-08-18 14:31 ` Chris Wilson
0 siblings, 0 replies; 10+ messages in thread
From: Chris Wilson @ 2016-08-18 14:31 UTC (permalink / raw)
To: Mika Kuoppala; +Cc: intel-gfx, Daniel Vetter, stable, Akash Goel
On Thu, Aug 18, 2016 at 04:59:35PM +0300, Mika Kuoppala wrote:
> Chris Wilson <chris@chris-wilson.co.uk> writes:
>
> > If userspace is asynchronously streaming into the batch or other
> > execobjects, we may not flush those writes along with a change in cache
> > domain (as there is no change). Therefore those writes may end up in
> > internal chipset buffers and not visible to the GPU upon execution. We
> > must issue a flush command or otherwise we encounter incoherency in the
> > batchbuffers and the GPU executing invalid commands (i.e. hanging) quite
> > regularly.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90841
> > Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user...")
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Akash Goel <akash.goel@intel.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > Tested-by: Matti H�m�l�inen <ccr@tnsp.org>
> > Cc: stable@vger.kernel.org
> > ---
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +++----------
> > 1 file changed, 3 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 699315304748..bce587abc601 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -1015,8 +1015,6 @@ i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request *req,
> > {
> > const unsigned int other_rings = eb_other_engines(req);
> > struct i915_vma *vma;
> > - uint32_t flush_domains = 0;
> > - bool flush_chipset = false;
> > int ret;
> >
> > list_for_each_entry(vma, vmas, exec_list) {
> > @@ -1029,16 +1027,11 @@ i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request *req,
> > }
> >
> > if (obj->base.write_domain & I915_GEM_DOMAIN_CPU)
> > - flush_chipset |= i915_gem_clflush_object(obj, false);
> > -
> > - flush_domains |= obj->base.write_domain;
> > + i915_gem_clflush_object(obj, false);
> > }
> >
> > - if (flush_chipset)
> > - i915_gem_chipset_flush(req->engine->i915);
> > -
> > - if (flush_domains & I915_GEM_DOMAIN_GTT)
> > - wmb();
>
> Was a bit worried about this vanishing.
>
> But after chatting with Chris and also founding this:
> https://lwn.net/Articles/174655/
> [in I386 AND X86_64 SPECIFIC NOTES]
>
> I am convinced that the uncached write to force the chipset_flush
> will be strong barrier enough.
>
> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Fwiw, the v2 that was meant to be here puts the wmb() back into
i915_gem_chipset_flush() so that we always have at least an sfence. It
should be redundant, but it shouldn't be noticeable either.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] drm/i915: Unconditionally flush any chipset buffers before execbuf
@ 2016-08-18 14:31 ` Chris Wilson
0 siblings, 0 replies; 10+ messages in thread
From: Chris Wilson @ 2016-08-18 14:31 UTC (permalink / raw)
To: Mika Kuoppala; +Cc: Daniel Vetter, intel-gfx, Akash Goel, stable
On Thu, Aug 18, 2016 at 04:59:35PM +0300, Mika Kuoppala wrote:
> Chris Wilson <chris@chris-wilson.co.uk> writes:
>
> > If userspace is asynchronously streaming into the batch or other
> > execobjects, we may not flush those writes along with a change in cache
> > domain (as there is no change). Therefore those writes may end up in
> > internal chipset buffers and not visible to the GPU upon execution. We
> > must issue a flush command or otherwise we encounter incoherency in the
> > batchbuffers and the GPU executing invalid commands (i.e. hanging) quite
> > regularly.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90841
> > Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user...")
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Akash Goel <akash.goel@intel.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > Tested-by: Matti Hämäläinen <ccr@tnsp.org>
> > Cc: stable@vger.kernel.org
> > ---
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +++----------
> > 1 file changed, 3 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 699315304748..bce587abc601 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -1015,8 +1015,6 @@ i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request *req,
> > {
> > const unsigned int other_rings = eb_other_engines(req);
> > struct i915_vma *vma;
> > - uint32_t flush_domains = 0;
> > - bool flush_chipset = false;
> > int ret;
> >
> > list_for_each_entry(vma, vmas, exec_list) {
> > @@ -1029,16 +1027,11 @@ i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request *req,
> > }
> >
> > if (obj->base.write_domain & I915_GEM_DOMAIN_CPU)
> > - flush_chipset |= i915_gem_clflush_object(obj, false);
> > -
> > - flush_domains |= obj->base.write_domain;
> > + i915_gem_clflush_object(obj, false);
> > }
> >
> > - if (flush_chipset)
> > - i915_gem_chipset_flush(req->engine->i915);
> > -
> > - if (flush_domains & I915_GEM_DOMAIN_GTT)
> > - wmb();
>
> Was a bit worried about this vanishing.
>
> But after chatting with Chris and also founding this:
> https://lwn.net/Articles/174655/
> [in I386 AND X86_64 SPECIFIC NOTES]
>
> I am convinced that the uncached write to force the chipset_flush
> will be strong barrier enough.
>
> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Fwiw, the v2 that was meant to be here puts the wmb() back into
i915_gem_chipset_flush() so that we always have at least an sfence. It
should be redundant, but it shouldn't be noticeable either.
-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] agp/intel: Flush chipset writes after updating a single PTE
2016-08-18 13:12 ` [PATCH 2/2] agp/intel: Flush chipset writes after updating a single PTE Chris Wilson
@ 2016-08-18 15:18 ` Mika Kuoppala
0 siblings, 0 replies; 10+ messages in thread
From: Mika Kuoppala @ 2016-08-18 15:18 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: Ankitprasad Sharma, drm-intel-fixes
Chris Wilson <chris@chris-wilson.co.uk> writes:
> After we update one PTE for a page, the caller expects to be able to
> immediately use that through a GGTT read/write. To comply with the
> callers expectations we therefore need to flush the chipset buffers
> before returning.
>
> Reported-by: Matti Hämäläinen <ccr@tnsp.org>
> Fixes: d6473f566417 ("drm/i915: Add support for mapping an object page...")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
> Cc: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Tested-by: Matti Hämäläinen <ccr@tnsp.org>
> Cc: drm-intel-fixes@lists.freedesktop.org
> ---
> drivers/char/agp/intel-gtt.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
> index 44311296ec02..0f7d28a98b9a 100644
> --- a/drivers/char/agp/intel-gtt.c
> +++ b/drivers/char/agp/intel-gtt.c
> @@ -845,6 +845,8 @@ void intel_gtt_insert_page(dma_addr_t addr,
> unsigned int flags)
> {
> intel_private.driver->write_entry(addr, pg, flags);
> + if (intel_private.driver->chipset_flush)
> + intel_private.driver->chipset_flush();
> }
> EXPORT_SYMBOL(intel_gtt_insert_page);
>
> --
> 2.9.3
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
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-08-18 15:18 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-18 13:12 [PATCH 1/2] drm/i915: Unconditionally flush any chipset buffers before execbuf Chris Wilson
2016-08-18 13:12 ` Chris Wilson
2016-08-18 13:12 ` [PATCH 2/2] agp/intel: Flush chipset writes after updating a single PTE Chris Wilson
2016-08-18 15:18 ` Mika Kuoppala
2016-08-18 13:33 ` [PATCH v2] drm/i915: Fallback to single page pwrite/pread if unable to release fence Chris Wilson
2016-08-18 13:52 ` ✓ Ro.CI.BAT: success for series starting with [1/2] drm/i915: Unconditionally flush any chipset buffers before execbuf Patchwork
2016-08-18 13:59 ` [PATCH 1/2] " Mika Kuoppala
2016-08-18 14:31 ` [Intel-gfx] " Chris Wilson
2016-08-18 14:31 ` Chris Wilson
2016-08-18 14:18 ` ✗ Ro.CI.BAT: warning for series starting with [v2] drm/i915: Fallback to single page pwrite/pread if unable to release fence (rev2) 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.