* [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD
@ 2020-04-30 22:10 Jason A. Donenfeld
2020-05-01 10:42 ` Sebastian Andrzej Siewior
` (5 more replies)
0 siblings, 6 replies; 14+ messages in thread
From: Jason A. Donenfeld @ 2020-04-30 22:10 UTC (permalink / raw)
To: linux-kernel, intel-gfx, dri-devel, bigeasy, tglx, chris
Cc: Jason A. Donenfeld, stable
Sometimes it's not okay to use SIMD registers, the conditions for which
have changed subtly from kernel release to kernel release. Usually the
pattern is to check for may_use_simd() and then fallback to using
something slower in the unlikely case SIMD registers aren't available.
So, this patch fixes up i915's accelerated memcpy routines to fallback
to boring memcpy if may_use_simd() is false.
Cc: stable@vger.kernel.org
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
drivers/gpu/drm/i915/i915_memcpy.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_memcpy.c b/drivers/gpu/drm/i915/i915_memcpy.c
index fdd550405fd3..7c0e022586bc 100644
--- a/drivers/gpu/drm/i915/i915_memcpy.c
+++ b/drivers/gpu/drm/i915/i915_memcpy.c
@@ -24,6 +24,7 @@
#include <linux/kernel.h>
#include <asm/fpu/api.h>
+#include <asm/simd.h>
#include "i915_memcpy.h"
@@ -38,6 +39,12 @@ static DEFINE_STATIC_KEY_FALSE(has_movntdqa);
#ifdef CONFIG_AS_MOVNTDQA
static void __memcpy_ntdqa(void *dst, const void *src, unsigned long len)
{
+ if (unlikely(!may_use_simd())) {
+ memcpy(dst, src, len);
+ return;
+ }
+
+
kernel_fpu_begin();
while (len >= 4) {
@@ -67,6 +74,11 @@ static void __memcpy_ntdqa(void *dst, const void *src, unsigned long len)
static void __memcpy_ntdqu(void *dst, const void *src, unsigned long len)
{
+ if (unlikely(!may_use_simd())) {
+ memcpy(dst, src, len);
+ return;
+ }
+
kernel_fpu_begin();
while (len >= 4) {
--
2.26.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD
2020-04-30 22:10 [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD Jason A. Donenfeld
@ 2020-05-01 10:42 ` Sebastian Andrzej Siewior
2020-05-01 11:34 ` David Laight
2020-05-01 21:54 ` Jason A. Donenfeld
2020-05-01 17:19 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
` (4 subsequent siblings)
5 siblings, 2 replies; 14+ messages in thread
From: Sebastian Andrzej Siewior @ 2020-05-01 10:42 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: intel-gfx, linux-kernel, stable, chris, dri-devel, tglx
On 2020-04-30 16:10:16 [-0600], Jason A. Donenfeld wrote:
> Sometimes it's not okay to use SIMD registers, the conditions for which
> have changed subtly from kernel release to kernel release. Usually the
> pattern is to check for may_use_simd() and then fallback to using
> something slower in the unlikely case SIMD registers aren't available.
> So, this patch fixes up i915's accelerated memcpy routines to fallback
> to boring memcpy if may_use_simd() is false.
That would indicate that these functions are used from IRQ/softirq which
break otherwise if the kernel is also using the registers. The crypto
code uses it for that purpose.
So
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
May I ask how large the memcpy can be? I'm asking in case it is large
and an explicit rescheduling point might be needed.
> Cc: stable@vger.kernel.org
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Sebastian
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD
2020-05-01 10:42 ` Sebastian Andrzej Siewior
@ 2020-05-01 11:34 ` David Laight
2020-05-01 21:54 ` Jason A. Donenfeld
1 sibling, 0 replies; 14+ messages in thread
From: David Laight @ 2020-05-01 11:34 UTC (permalink / raw)
To: 'Sebastian Andrzej Siewior', Jason A. Donenfeld
Cc: intel-gfx, linux-kernel, stable, chris, dri-devel, tglx
From: Sebastian Andrzej Siewior
> Sent: 01 May 2020 11:42
> On 2020-04-30 16:10:16 [-0600], Jason A. Donenfeld wrote:
> > Sometimes it's not okay to use SIMD registers, the conditions for which
> > have changed subtly from kernel release to kernel release. Usually the
> > pattern is to check for may_use_simd() and then fallback to using
> > something slower in the unlikely case SIMD registers aren't available.
> > So, this patch fixes up i915's accelerated memcpy routines to fallback
> > to boring memcpy if may_use_simd() is false.
>
> That would indicate that these functions are used from IRQ/softirq which
> break otherwise if the kernel is also using the registers. The crypto
> code uses it for that purpose.
>
> So
> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>
> May I ask how large the memcpy can be? I'm asking in case it is large
> and an explicit rescheduling point might be needed.
It is also quite likely that a 'rep movs' copy will be at least just as
fast on modern hardware.
Clearly if you are copying to/from PCIe memory you need the largest
resisters possible - but I think the graphics buffers are mapped cached?
(Otherwise I wouldn't see 3ms 'spins' while it invalidates the
entire screen buffer cache.)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: check to see if SIMD registers are available before using SIMD
2020-04-30 22:10 [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD Jason A. Donenfeld
2020-05-01 10:42 ` Sebastian Andrzej Siewior
@ 2020-05-01 17:19 ` Patchwork
2020-05-01 17:43 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
` (3 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2020-05-01 17:19 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: check to see if SIMD registers are available before using SIMD
URL : https://patchwork.freedesktop.org/series/76825/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
962131944f1f drm/i915: check to see if SIMD registers are available before using SIMD
-:38: CHECK:LINE_SPACING: Please don't use multiple blank lines
#38: FILE: drivers/gpu/drm/i915/i915_memcpy.c:46:
+
+
total: 0 errors, 0 warnings, 1 checks, 30 lines checked
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: check to see if SIMD registers are available before using SIMD
2020-04-30 22:10 [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD Jason A. Donenfeld
2020-05-01 10:42 ` Sebastian Andrzej Siewior
2020-05-01 17:19 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
@ 2020-05-01 17:43 ` Patchwork
2020-05-01 18:07 ` [Intel-gfx] [PATCH] " Christoph Hellwig
` (2 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2020-05-01 17:43 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: check to see if SIMD registers are available before using SIMD
URL : https://patchwork.freedesktop.org/series/76825/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8407 -> Patchwork_17544
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/index.html
Known issues
------------
Here are the changes found in Patchwork_17544 that come from known issues:
### IGT changes ###
#### Possible fixes ####
* igt@i915_selftest@live@execlists:
- fi-skl-guc: [INCOMPLETE][1] ([i915#1795]) -> [PASS][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/fi-skl-guc/igt@i915_selftest@live@execlists.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/fi-skl-guc/igt@i915_selftest@live@execlists.html
[i915#1795]: https://gitlab.freedesktop.org/drm/intel/issues/1795
Participating hosts (50 -> 43)
------------------------------
Missing (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_8407 -> Patchwork_17544
CI-20190529: 20190529
CI_DRM_8407: ecb91f743598d9d646fa046c7341058e48494e7c @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5626: f27fdfff026276ac75c69e487c929a843f66f6ca @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17544: 962131944f1f279983832e13cdf45517f2abfa06 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
962131944f1f drm/i915: check to see if SIMD registers are available before using SIMD
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD
2020-04-30 22:10 [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD Jason A. Donenfeld
` (2 preceding siblings ...)
2020-05-01 17:43 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
@ 2020-05-01 18:07 ` Christoph Hellwig
2020-05-01 21:55 ` Jason A. Donenfeld
2020-05-03 20:20 ` Chris Wilson
2020-05-01 20:26 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork
2020-05-03 20:30 ` [Intel-gfx] [PATCH] " Chris Wilson
5 siblings, 2 replies; 14+ messages in thread
From: Christoph Hellwig @ 2020-05-01 18:07 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: intel-gfx, linux-kernel, dri-devel, chris, stable, tglx, bigeasy
On Thu, Apr 30, 2020 at 04:10:16PM -0600, Jason A. Donenfeld wrote:
> Sometimes it's not okay to use SIMD registers, the conditions for which
> have changed subtly from kernel release to kernel release. Usually the
> pattern is to check for may_use_simd() and then fallback to using
> something slower in the unlikely case SIMD registers aren't available.
> So, this patch fixes up i915's accelerated memcpy routines to fallback
> to boring memcpy if may_use_simd() is false.
Err, why does i915 implements its own uncached memcpy instead of relying
on core functionality to start with?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: check to see if SIMD registers are available before using SIMD
2020-04-30 22:10 [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD Jason A. Donenfeld
` (3 preceding siblings ...)
2020-05-01 18:07 ` [Intel-gfx] [PATCH] " Christoph Hellwig
@ 2020-05-01 20:26 ` Patchwork
2020-05-03 20:30 ` [Intel-gfx] [PATCH] " Chris Wilson
5 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2020-05-01 20:26 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: check to see if SIMD registers are available before using SIMD
URL : https://patchwork.freedesktop.org/series/76825/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8407_full -> Patchwork_17544_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Known issues
------------
Here are the changes found in Patchwork_17544_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@i915_suspend@fence-restore-untiled:
- shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-kbl4/igt@i915_suspend@fence-restore-untiled.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-kbl6/igt@i915_suspend@fence-restore-untiled.html
* igt@kms_cursor_legacy@pipe-d-torture-bo:
- shard-tglb: [PASS][3] -> [DMESG-WARN][4] ([i915#128])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-tglb6/igt@kms_cursor_legacy@pipe-d-torture-bo.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-tglb6/igt@kms_cursor_legacy@pipe-d-torture-bo.html
* igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#52] / [i915#54])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-glk1/igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-glk7/igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled.html
* igt@kms_lease@lease_again:
- shard-snb: [PASS][7] -> [SKIP][8] ([fdo#109271]) +1 similar issue
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-snb1/igt@kms_lease@lease_again.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-snb5/igt@kms_lease@lease_again.html
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
- shard-skl: [PASS][9] -> [FAIL][10] ([i915#53])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-skl7/igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-skl6/igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#180])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-apl2/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-apl4/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265]) +1 similar issue
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-skl7/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-skl6/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
* igt@kms_psr@psr2_cursor_mmap_cpu:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +1 similar issue
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-iclb6/igt@kms_psr@psr2_cursor_mmap_cpu.html
#### Possible fixes ####
* igt@gem_exec_params@invalid-bsd-ring:
- shard-iclb: [SKIP][17] ([fdo#109276]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-iclb3/igt@gem_exec_params@invalid-bsd-ring.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-iclb4/igt@gem_exec_params@invalid-bsd-ring.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-skl: [INCOMPLETE][19] ([i915#300]) -> [PASS][20]
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-skl10/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-skl9/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
* igt@kms_cursor_legacy@pipe-b-torture-bo:
- shard-snb: [DMESG-WARN][21] ([i915#128]) -> [PASS][22]
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-snb6/igt@kms_cursor_legacy@pipe-b-torture-bo.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-snb2/igt@kms_cursor_legacy@pipe-b-torture-bo.html
* igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
- shard-snb: [SKIP][23] ([fdo#109271]) -> [PASS][24] +1 similar issue
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-snb2/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-snb6/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-apl: [DMESG-WARN][25] ([i915#180]) -> [PASS][26] +1 similar issue
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-apl2/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-apl4/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [FAIL][27] ([fdo#108145] / [i915#265]) -> [PASS][28]
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-skl6/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-skl8/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: [SKIP][29] ([fdo#109441]) -> [PASS][30] +1 similar issue
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-iclb8/igt@kms_psr@psr2_cursor_render.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-kbl: [DMESG-WARN][31] ([i915#180]) -> [PASS][32] +1 similar issue
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-kbl4/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-kbl7/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
#### Warnings ####
* igt@i915_pm_rpm@modeset-lpsp:
- shard-snb: [SKIP][33] ([fdo#109271]) -> [INCOMPLETE][34] ([i915#82])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-snb5/igt@i915_pm_rpm@modeset-lpsp.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-snb6/igt@i915_pm_rpm@modeset-lpsp.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-apl: [FAIL][35] ([fdo#108145] / [i915#265] / [i915#95]) -> [FAIL][36] ([fdo#108145] / [i915#265])
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8407/shard-apl3/igt@kms_plane_alpha_blend@pipe-a-alpha-basic.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/shard-apl1/igt@kms_plane_alpha_blend@pipe-a-alpha-basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[i915#128]: https://gitlab.freedesktop.org/drm/intel/issues/128
[i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#300]: https://gitlab.freedesktop.org/drm/intel/issues/300
[i915#52]: https://gitlab.freedesktop.org/drm/intel/issues/52
[i915#53]: https://gitlab.freedesktop.org/drm/intel/issues/53
[i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#82]: https://gitlab.freedesktop.org/drm/intel/issues/82
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_8407 -> Patchwork_17544
CI-20190529: 20190529
CI_DRM_8407: ecb91f743598d9d646fa046c7341058e48494e7c @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5626: f27fdfff026276ac75c69e487c929a843f66f6ca @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17544: 962131944f1f279983832e13cdf45517f2abfa06 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17544/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD
2020-05-01 10:42 ` Sebastian Andrzej Siewior
2020-05-01 11:34 ` David Laight
@ 2020-05-01 21:54 ` Jason A. Donenfeld
1 sibling, 0 replies; 14+ messages in thread
From: Jason A. Donenfeld @ 2020-05-01 21:54 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: intel-gfx, LKML, stable, Chris Wilson, dri-devel, Thomas Gleixner
On Fri, May 1, 2020 at 4:42 AM Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Thanks.
>
> May I ask how large the memcpy can be? I'm asking in case it is large
> and an explicit rescheduling point might be needed.
Yea I was worried about that too. I'm not an i915 developer, but so
far as I can tell:
- The path from intel_engine_cmd_parser is <= 256 KiB for "known
users", so that's rather large.
- The path from perf_memcpy is either 4k, 64k, or 4M, depending on the
type of object, so that seems gigantic, but I think that might be
selftest code.
- The path from compress_page appears to be PAGE_SIZE, so 4k, which
meshes with the limits we set agreed on few weeks ago for the crypto
stuff.
- The path from guc_read_update_log_buffer appears to be 8k, 32k, 2M,
or 8M, depending on the type of object, so that seems absurdly huge
and doesn't appear to be selftest code either like the other case.
I have no doubt the i915 developers will jump in here waving their
arms, but either way, it sure seems to me like you might have a point.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD
2020-05-01 18:07 ` [Intel-gfx] [PATCH] " Christoph Hellwig
@ 2020-05-01 21:55 ` Jason A. Donenfeld
2020-05-03 20:20 ` Chris Wilson
1 sibling, 0 replies; 14+ messages in thread
From: Jason A. Donenfeld @ 2020-05-01 21:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: intel-gfx, LKML, dri-devel, Chris Wilson, stable,
Thomas Gleixner, Sebastian Siewior
On Fri, May 1, 2020 at 12:07 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Thu, Apr 30, 2020 at 04:10:16PM -0600, Jason A. Donenfeld wrote:
> > Sometimes it's not okay to use SIMD registers, the conditions for which
> > have changed subtly from kernel release to kernel release. Usually the
> > pattern is to check for may_use_simd() and then fallback to using
> > something slower in the unlikely case SIMD registers aren't available.
> > So, this patch fixes up i915's accelerated memcpy routines to fallback
> > to boring memcpy if may_use_simd() is false.
>
> Err, why does i915 implements its own uncached memcpy instead of relying
> on core functionality to start with?
I was wondering the same. It sure does seem like this ought to be more
generalized functionality, with a name that represents the type of
transfer it's optimized for (wc or similar).
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD
2020-05-01 18:07 ` [Intel-gfx] [PATCH] " Christoph Hellwig
2020-05-01 21:55 ` Jason A. Donenfeld
@ 2020-05-03 20:20 ` Chris Wilson
2020-05-04 16:03 ` Christoph Hellwig
1 sibling, 1 reply; 14+ messages in thread
From: Chris Wilson @ 2020-05-03 20:20 UTC (permalink / raw)
To: Jason A. Donenfeld, Christoph Hellwig
Cc: intel-gfx, linux-kernel, stable, dri-devel, tglx, bigeasy
Quoting Christoph Hellwig (2020-05-01 19:07:31)
> On Thu, Apr 30, 2020 at 04:10:16PM -0600, Jason A. Donenfeld wrote:
> > Sometimes it's not okay to use SIMD registers, the conditions for which
> > have changed subtly from kernel release to kernel release. Usually the
> > pattern is to check for may_use_simd() and then fallback to using
> > something slower in the unlikely case SIMD registers aren't available.
> > So, this patch fixes up i915's accelerated memcpy routines to fallback
> > to boring memcpy if may_use_simd() is false.
>
> Err, why does i915 implements its own uncached memcpy instead of relying
> on core functionality to start with?
What is this core functionality that provides movntqda?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD
2020-04-30 22:10 [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD Jason A. Donenfeld
` (4 preceding siblings ...)
2020-05-01 20:26 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork
@ 2020-05-03 20:30 ` Chris Wilson
2020-05-03 20:35 ` Jason A. Donenfeld
5 siblings, 1 reply; 14+ messages in thread
From: Chris Wilson @ 2020-05-03 20:30 UTC (permalink / raw)
To: Jason A. Donenfeld, bigeasy, dri-devel, intel-gfx, linux-kernel, tglx
Cc: Jason A. Donenfeld, stable
Quoting Jason A. Donenfeld (2020-04-30 23:10:16)
> Sometimes it's not okay to use SIMD registers, the conditions for which
> have changed subtly from kernel release to kernel release. Usually the
> pattern is to check for may_use_simd() and then fallback to using
> something slower in the unlikely case SIMD registers aren't available.
> So, this patch fixes up i915's accelerated memcpy routines to fallback
> to boring memcpy if may_use_simd() is false.
>
> Cc: stable@vger.kernel.org
The same argument as on the previous submission is that we return to the
caller if we can't use movntqda as their fallback path should be faster
than uncached memcpy.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD
2020-05-03 20:30 ` [Intel-gfx] [PATCH] " Chris Wilson
@ 2020-05-03 20:35 ` Jason A. Donenfeld
0 siblings, 0 replies; 14+ messages in thread
From: Jason A. Donenfeld @ 2020-05-03 20:35 UTC (permalink / raw)
To: Chris Wilson
Cc: Sebastian Siewior, LKML, stable, dri-devel, Thomas Gleixner, intel-gfx
On Sun, May 3, 2020 at 2:30 PM Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Quoting Jason A. Donenfeld (2020-04-30 23:10:16)
> > Sometimes it's not okay to use SIMD registers, the conditions for which
> > have changed subtly from kernel release to kernel release. Usually the
> > pattern is to check for may_use_simd() and then fallback to using
> > something slower in the unlikely case SIMD registers aren't available.
> > So, this patch fixes up i915's accelerated memcpy routines to fallback
> > to boring memcpy if may_use_simd() is false.
> >
> > Cc: stable@vger.kernel.org
>
> The same argument as on the previous submission is that we return to the
> caller if we can't use movntqda as their fallback path should be faster
> than uncached memcpy.
Oh, THAT's what you meant before. Okay, will follow up.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD
2020-05-03 20:20 ` Chris Wilson
@ 2020-05-04 16:03 ` Christoph Hellwig
2020-05-04 16:15 ` David Laight
0 siblings, 1 reply; 14+ messages in thread
From: Christoph Hellwig @ 2020-05-04 16:03 UTC (permalink / raw)
To: Chris Wilson
Cc: Jason A. Donenfeld, bigeasy, linux-kernel, dri-devel,
Christoph Hellwig, stable, tglx, intel-gfx
On Sun, May 03, 2020 at 09:20:19PM +0100, Chris Wilson wrote:
> > Err, why does i915 implements its own uncached memcpy instead of relying
> > on core functionality to start with?
>
> What is this core functionality that provides movntqda?
A sensible name might be memcpy_uncached or mempcy_nontemporal.
But the important point is that this should be arch code with a common
fallback rather than hacking it up in drivers.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD
2020-05-04 16:03 ` Christoph Hellwig
@ 2020-05-04 16:15 ` David Laight
0 siblings, 0 replies; 14+ messages in thread
From: David Laight @ 2020-05-04 16:15 UTC (permalink / raw)
To: 'Christoph Hellwig', Chris Wilson
Cc: Jason A. Donenfeld, bigeasy, linux-kernel, dri-devel, stable,
tglx, intel-gfx
From: Christoph Hellwig
> Sent: 04 May 2020 17:03
>
> On Sun, May 03, 2020 at 09:20:19PM +0100, Chris Wilson wrote:
> > > Err, why does i915 implements its own uncached memcpy instead of relying
> > > on core functionality to start with?
> >
> > What is this core functionality that provides movntqda?
>
> A sensible name might be memcpy_uncached or mempcy_nontemporal.
> But the important point is that this should be arch code with a common
> fallback rather than hacking it up in drivers.
More the point, you are trying to do a copy where:
1) The kernel isn't expected to read the data - so can bypass the cache.
and maybe:
2) The data needs flushing from the cache to actual memory.
and maybe:
3) The cache lines need invalidating.
The fallbacks depend on the required behaviour.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-05-04 17:32 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-30 22:10 [Intel-gfx] [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD Jason A. Donenfeld
2020-05-01 10:42 ` Sebastian Andrzej Siewior
2020-05-01 11:34 ` David Laight
2020-05-01 21:54 ` Jason A. Donenfeld
2020-05-01 17:19 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2020-05-01 17:43 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-05-01 18:07 ` [Intel-gfx] [PATCH] " Christoph Hellwig
2020-05-01 21:55 ` Jason A. Donenfeld
2020-05-03 20:20 ` Chris Wilson
2020-05-04 16:03 ` Christoph Hellwig
2020-05-04 16:15 ` David Laight
2020-05-01 20:26 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork
2020-05-03 20:30 ` [Intel-gfx] [PATCH] " Chris Wilson
2020-05-03 20:35 ` Jason A. Donenfeld
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).