[igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.

[igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.

[Mark Yacoub]

Some devices such as amdgpu do not support imported buffers.
Filter out those devices.
Tested on Zork with chromeos-kernel-5_4.

Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
---
 tests/kms_prime.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/tests/kms_prime.c b/tests/kms_prime.c
index 8cb2ca2a..480c7eb4 100644
--- a/tests/kms_prime.c
+++ b/tests/kms_prime.c
@@ -249,6 +249,16 @@ static void test_crc(int exporter_fd, int importer_fd)
 	igt_display_fini(&display);
 }
 
+/* The test attempts to import the buffer object from one device to another.
+ * Filter out devices that aren't capable of doing this.
+ */
+bool does_device_support_dmabuf_import(int fd) {
+	/* AMDGPU uses VRAM. Any use of the fb will migrate it to VRAM, which is not sensible for
+	 * an imported dma-buf.
+	 */
+	return !is_amdgpu_device(fd);
+}
+
 igt_main
 {
 	igt_fixture
@@ -262,10 +272,10 @@ igt_main
 
 		/* ANY = anything that is not VGEM */
 		first_fd = __drm_open_driver_another(0, DRIVER_ANY | DRIVER_VGEM);
-		igt_require(first_fd >= 0);
+		igt_require(first_fd >= 0 && does_device_support_dmabuf_import(first_fd));
 
 		second_fd = __drm_open_driver_another(1, DRIVER_ANY | DRIVER_VGEM);
-		igt_require(second_fd >= 0);
+		igt_require(second_fd >= 0 && does_device_support_dmabuf_import(second_fd));
 
 		if (has_prime_export(first_fd) &&
 		    has_prime_import(second_fd))
-- 
2.32.0.272.g935e593368-goog

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.BAT: success for tests/kms_prime: Filter out devices that can't import buffers.

[Patchwork]

[-- Attachment #1.1: Type: text/plain, Size: 2963 bytes --]

== Series Details ==

Series: tests/kms_prime: Filter out devices that can't import buffers.
URL   : https://patchwork.freedesktop.org/series/91466/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10220 -> IGTPW_5920
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/index.html

Known issues
------------

  Here are the changes found in IGTPW_5920 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@amdgpu/amd_basic@cs-gfx:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][1] ([fdo#109271]) +1 similar issue
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/fi-kbl-soraka/igt@amdgpu/amd_basic@cs-gfx.html

  * igt@i915_selftest@live@execlists:
    - fi-bsw-nick:        [PASS][2] -> [INCOMPLETE][3] ([i915#2782] / [i915#2940])
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/fi-bsw-nick/igt@i915_selftest@live@execlists.html
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/fi-bsw-nick/igt@i915_selftest@live@execlists.html

  * igt@runner@aborted:
    - fi-bsw-nick:        NOTRUN -> [FAIL][4] ([fdo#109271] / [i915#1436])
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/fi-bsw-nick/igt@runner@aborted.html

  
#### Possible fixes ####

  * igt@i915_selftest@live@gt_heartbeat:
    - {fi-tgl-dsi}:       [DMESG-FAIL][5] -> [PASS][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#3180]: https://gitlab.freedesktop.org/drm/intel/issues/3180
  [i915#3544]: https://gitlab.freedesktop.org/drm/intel/issues/3544


Participating hosts (44 -> 38)
------------------------------

  Missing    (6): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-bsw-cyan fi-dg1-1 fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * IGT: IGT_6105 -> IGTPW_5920

  CI-20190529: 20190529
  CI_DRM_10220: 1b77783fab8d920a675a3f6c8ee7de1eb206a19a @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_5920: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/index.html
  IGT_6105: 598a154680374e7875ae9ffc98425abc57398b2f @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/index.html

[-- Attachment #1.2: Type: text/html, Size: 3511 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.IGT: success for tests/kms_prime: Filter out devices that can't import buffers.

[Patchwork]

[-- Attachment #1.1: Type: text/plain, Size: 27859 bytes --]

== Series Details ==

Series: tests/kms_prime: Filter out devices that can't import buffers.
URL   : https://patchwork.freedesktop.org/series/91466/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10220_full -> IGTPW_5920_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/index.html

Known issues
------------

  Here are the changes found in IGTPW_5920_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_create@create-massive:
    - shard-iclb:         NOTRUN -> [DMESG-WARN][1] ([i915#3002])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb4/igt@gem_create@create-massive.html
    - shard-kbl:          NOTRUN -> [DMESG-WARN][2] ([i915#3002])
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-kbl4/igt@gem_create@create-massive.html
    - shard-tglb:         NOTRUN -> [DMESG-WARN][3] ([i915#3002])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-tglb5/igt@gem_create@create-massive.html
    - shard-glk:          NOTRUN -> [DMESG-WARN][4] ([i915#3002])
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-glk7/igt@gem_create@create-massive.html
    - shard-apl:          NOTRUN -> [DMESG-WARN][5] ([i915#3002])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl3/igt@gem_create@create-massive.html

  * igt@gem_ctx_persistence@smoketest:
    - shard-snb:          NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +6 similar issues
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-snb7/igt@gem_ctx_persistence@smoketest.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
    - shard-tglb:         [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-tglb5/igt@gem_exec_fair@basic-pace-share@rcs0.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-tglb3/igt@gem_exec_fair@basic-pace-share@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
    - shard-kbl:          [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-kbl7/igt@gem_exec_fair@basic-pace@rcs0.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-kbl6/igt@gem_exec_fair@basic-pace@rcs0.html

  * igt@gem_exec_fair@basic-sync@rcs0:
    - shard-kbl:          [PASS][11] -> [SKIP][12] ([fdo#109271])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-kbl7/igt@gem_exec_fair@basic-sync@rcs0.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-kbl6/igt@gem_exec_fair@basic-sync@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
    - shard-glk:          [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-glk6/igt@gem_exec_fair@basic-throttle@rcs0.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-glk4/igt@gem_exec_fair@basic-throttle@rcs0.html
    - shard-iclb:         [PASS][15] -> [FAIL][16] ([i915#2849])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-iclb4/igt@gem_exec_fair@basic-throttle@rcs0.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb4/igt@gem_exec_fair@basic-throttle@rcs0.html

  * igt@gem_exec_reloc@basic-wide-active@bcs0:
    - shard-apl:          NOTRUN -> [FAIL][17] ([i915#2389]) +3 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl6/igt@gem_exec_reloc@basic-wide-active@bcs0.html

  * igt@gem_exec_reloc@basic-wide-active@rcs0:
    - shard-snb:          NOTRUN -> [FAIL][18] ([i915#2389]) +2 similar issues
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-snb2/igt@gem_exec_reloc@basic-wide-active@rcs0.html

  * igt@gem_exec_reloc@basic-wide-active@vcs1:
    - shard-iclb:         NOTRUN -> [FAIL][19] ([i915#2389])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb2/igt@gem_exec_reloc@basic-wide-active@vcs1.html

  * igt@gem_huc_copy@huc-copy:
    - shard-apl:          NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#2190])
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl3/igt@gem_huc_copy@huc-copy.html

  * igt@gem_userptr_blits@vma-merge:
    - shard-apl:          NOTRUN -> [FAIL][21] ([i915#3318])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl1/igt@gem_userptr_blits@vma-merge.html

  * igt@i915_suspend@debugfs-reader:
    - shard-kbl:          [PASS][22] -> [INCOMPLETE][23] ([i915#155])
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-kbl3/igt@i915_suspend@debugfs-reader.html
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-kbl4/igt@i915_suspend@debugfs-reader.html

  * igt@kms_atomic_transition@plane-all-modeset-transition:
    - shard-iclb:         NOTRUN -> [SKIP][24] ([i915#1769])
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb5/igt@kms_atomic_transition@plane-all-modeset-transition.html
    - shard-tglb:         NOTRUN -> [SKIP][25] ([i915#1769])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-tglb7/igt@kms_atomic_transition@plane-all-modeset-transition.html

  * igt@kms_big_fb@yf-tiled-64bpp-rotate-270:
    - shard-tglb:         NOTRUN -> [SKIP][26] ([fdo#111615])
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-tglb8/igt@kms_big_fb@yf-tiled-64bpp-rotate-270.html
    - shard-iclb:         NOTRUN -> [SKIP][27] ([fdo#110723])
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb4/igt@kms_big_fb@yf-tiled-64bpp-rotate-270.html

  * igt@kms_chamelium@dp-mode-timings:
    - shard-apl:          NOTRUN -> [SKIP][28] ([fdo#109271] / [fdo#111827]) +31 similar issues
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl7/igt@kms_chamelium@dp-mode-timings.html

  * igt@kms_chamelium@hdmi-mode-timings:
    - shard-snb:          NOTRUN -> [SKIP][29] ([fdo#109271] / [fdo#111827]) +26 similar issues
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-snb2/igt@kms_chamelium@hdmi-mode-timings.html

  * igt@kms_chamelium@vga-edid-read:
    - shard-iclb:         NOTRUN -> [SKIP][30] ([fdo#109284] / [fdo#111827])
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb8/igt@kms_chamelium@vga-edid-read.html
    - shard-glk:          NOTRUN -> [SKIP][31] ([fdo#109271] / [fdo#111827]) +1 similar issue
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-glk7/igt@kms_chamelium@vga-edid-read.html
    - shard-kbl:          NOTRUN -> [SKIP][32] ([fdo#109271] / [fdo#111827]) +1 similar issue
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-kbl3/igt@kms_chamelium@vga-edid-read.html

  * igt@kms_color_chamelium@pipe-d-ctm-red-to-blue:
    - shard-tglb:         NOTRUN -> [SKIP][33] ([fdo#109284] / [fdo#111827]) +1 similar issue
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-tglb1/igt@kms_color_chamelium@pipe-d-ctm-red-to-blue.html
    - shard-iclb:         NOTRUN -> [SKIP][34] ([fdo#109278] / [fdo#109284] / [fdo#111827])
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb4/igt@kms_color_chamelium@pipe-d-ctm-red-to-blue.html

  * igt@kms_content_protection@srm:
    - shard-apl:          NOTRUN -> [TIMEOUT][35] ([i915#1319])
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl7/igt@kms_content_protection@srm.html

  * igt@kms_cursor_crc@pipe-b-cursor-256x256-sliding:
    - shard-tglb:         [PASS][36] -> [DMESG-WARN][37] ([i915#2868])
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-tglb5/igt@kms_cursor_crc@pipe-b-cursor-256x256-sliding.html
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-tglb5/igt@kms_cursor_crc@pipe-b-cursor-256x256-sliding.html

  * igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-ytiled:
    - shard-glk:          [PASS][38] -> [DMESG-FAIL][39] ([i915#118] / [i915#95])
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-glk8/igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-ytiled.html
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-glk8/igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-ytiled.html

  * igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible:
    - shard-tglb:         NOTRUN -> [SKIP][40] ([fdo#111825]) +5 similar issues
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-tglb2/igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible.html
    - shard-iclb:         NOTRUN -> [SKIP][41] ([fdo#109274]) +1 similar issue
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb2/igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
    - shard-apl:          [PASS][42] -> [DMESG-WARN][43] ([i915#180])
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-apl2/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl1/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html

  * igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile:
    - shard-snb:          NOTRUN -> [SKIP][44] ([fdo#109271]) +392 similar issues
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-snb5/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile.html
    - shard-tglb:         NOTRUN -> [SKIP][45] ([i915#2587])
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-tglb8/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile.html
    - shard-apl:          NOTRUN -> [SKIP][46] ([fdo#109271] / [i915#2642])
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl8/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile.html
    - shard-glk:          NOTRUN -> [SKIP][47] ([fdo#109271] / [i915#2642])
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-glk8/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile.html
    - shard-kbl:          NOTRUN -> [SKIP][48] ([fdo#109271] / [i915#2642])
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-kbl6/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile.html

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-cur-indfb-draw-pwrite:
    - shard-kbl:          NOTRUN -> [SKIP][49] ([fdo#109271]) +9 similar issues
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-kbl4/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-cur-indfb-draw-pwrite.html
    - shard-iclb:         NOTRUN -> [SKIP][50] ([fdo#109280]) +3 similar issues
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb3/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-cur-indfb-draw-pwrite.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d:
    - shard-apl:          NOTRUN -> [SKIP][51] ([fdo#109271] / [i915#533]) +2 similar issues
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl6/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d.html

  * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
    - shard-apl:          NOTRUN -> [FAIL][52] ([fdo#108145] / [i915#265]) +3 similar issues
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl8/igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb.html

  * igt@kms_plane_alpha_blend@pipe-c-alpha-transparent-fb:
    - shard-apl:          NOTRUN -> [FAIL][53] ([i915#265])
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl8/igt@kms_plane_alpha_blend@pipe-c-alpha-transparent-fb.html

  * igt@kms_psr2_sf@cursor-plane-update-sf:
    - shard-tglb:         NOTRUN -> [SKIP][54] ([i915#2920]) +1 similar issue
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-tglb2/igt@kms_psr2_sf@cursor-plane-update-sf.html
    - shard-iclb:         NOTRUN -> [SKIP][55] ([i915#658])
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb6/igt@kms_psr2_sf@cursor-plane-update-sf.html

  * igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-1:
    - shard-apl:          NOTRUN -> [SKIP][56] ([fdo#109271] / [i915#658]) +8 similar issues
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl7/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-1.html

  * igt@kms_psr2_sf@plane-move-sf-dmg-area-1:
    - shard-kbl:          NOTRUN -> [SKIP][57] ([fdo#109271] / [i915#658]) +1 similar issue
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-kbl6/igt@kms_psr2_sf@plane-move-sf-dmg-area-1.html
    - shard-iclb:         NOTRUN -> [SKIP][58] ([i915#2920])
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb2/igt@kms_psr2_sf@plane-move-sf-dmg-area-1.html

  * igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-5:
    - shard-glk:          NOTRUN -> [SKIP][59] ([fdo#109271] / [i915#658]) +2 similar issues
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-glk3/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-5.html

  * igt@kms_psr2_su@page_flip:
    - shard-iclb:         [PASS][60] -> [SKIP][61] ([fdo#109642] / [fdo#111068] / [i915#658])
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-iclb2/igt@kms_psr2_su@page_flip.html
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb3/igt@kms_psr2_su@page_flip.html

  * igt@kms_setmode@basic:
    - shard-snb:          NOTRUN -> [FAIL][62] ([i915#31])
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-snb7/igt@kms_setmode@basic.html

  * igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
    - shard-kbl:          [PASS][63] -> [INCOMPLETE][64] ([i915#155] / [i915#2405])
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-kbl2/igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-kbl4/igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend.html

  * igt@kms_vblank@pipe-d-query-busy-hang:
    - shard-glk:          NOTRUN -> [SKIP][65] ([fdo#109271]) +10 similar issues
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-glk7/igt@kms_vblank@pipe-d-query-busy-hang.html
    - shard-iclb:         NOTRUN -> [SKIP][66] ([fdo#109278])
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb8/igt@kms_vblank@pipe-d-query-busy-hang.html

  * igt@kms_writeback@writeback-pixel-formats:
    - shard-apl:          NOTRUN -> [SKIP][67] ([fdo#109271] / [i915#2437])
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl2/igt@kms_writeback@writeback-pixel-formats.html

  * igt@nouveau_crc@pipe-b-ctx-flip-skip-current-frame:
    - shard-apl:          NOTRUN -> [SKIP][68] ([fdo#109271]) +248 similar issues
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl2/igt@nouveau_crc@pipe-b-ctx-flip-skip-current-frame.html

  * igt@perf@polling-parameterized:
    - shard-apl:          [PASS][69] -> [FAIL][70] ([i915#1542])
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-apl7/igt@perf@polling-parameterized.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl3/igt@perf@polling-parameterized.html

  * igt@prime_nv_pcopy@test3_1:
    - shard-tglb:         NOTRUN -> [SKIP][71] ([fdo#109291])
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-tglb8/igt@prime_nv_pcopy@test3_1.html
    - shard-iclb:         NOTRUN -> [SKIP][72] ([fdo#109291])
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb1/igt@prime_nv_pcopy@test3_1.html

  * igt@sysfs_clients@fair-1:
    - shard-apl:          NOTRUN -> [SKIP][73] ([fdo#109271] / [i915#2994]) +5 similar issues
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl3/igt@sysfs_clients@fair-1.html

  
#### Possible fixes ####

  * igt@gem_eio@unwedge-stress:
    - shard-tglb:         [TIMEOUT][74] ([i915#2369] / [i915#3063]) -> [PASS][75]
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-tglb1/igt@gem_eio@unwedge-stress.html
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-tglb1/igt@gem_eio@unwedge-stress.html

  * igt@gem_exec_fair@basic-none@rcs0:
    - shard-glk:          [FAIL][76] ([i915#2842]) -> [PASS][77] +1 similar issue
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-glk7/igt@gem_exec_fair@basic-none@rcs0.html
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-glk8/igt@gem_exec_fair@basic-none@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
    - shard-kbl:          [FAIL][78] ([i915#2842]) -> [PASS][79] +3 similar issues
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-kbl1/igt@gem_exec_fair@basic-none@vcs0.html
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-kbl4/igt@gem_exec_fair@basic-none@vcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
    - shard-tglb:         [FAIL][80] ([i915#2842]) -> [PASS][81]
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-tglb2/igt@gem_exec_fair@basic-pace@rcs0.html
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-tglb8/igt@gem_exec_fair@basic-pace@rcs0.html

  * igt@gem_exec_flush@basic-wb-rw-default:
    - shard-glk:          [INCOMPLETE][82] ([i915#2055]) -> [PASS][83]
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-glk8/igt@gem_exec_flush@basic-wb-rw-default.html
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-glk8/igt@gem_exec_flush@basic-wb-rw-default.html

  * igt@gem_mmap_gtt@cpuset-big-copy:
    - shard-iclb:         [FAIL][84] ([i915#2428]) -> [PASS][85]
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-iclb4/igt@gem_mmap_gtt@cpuset-big-copy.html
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb5/igt@gem_mmap_gtt@cpuset-big-copy.html

  * igt@i915_pm_dc@dc6-psr:
    - shard-iclb:         [FAIL][86] ([i915#454]) -> [PASS][87]
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-iclb4/igt@i915_pm_dc@dc6-psr.html
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb8/igt@i915_pm_dc@dc6-psr.html

  * igt@i915_selftest@live@hangcheck:
    - shard-snb:          [INCOMPLETE][88] ([i915#2782]) -> [PASS][89]
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-snb6/igt@i915_selftest@live@hangcheck.html
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-snb2/igt@i915_selftest@live@hangcheck.html

  * igt@kms_async_flips@alternate-sync-async-flip:
    - shard-tglb:         [FAIL][90] ([i915#2521]) -> [PASS][91]
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-tglb2/igt@kms_async_flips@alternate-sync-async-flip.html
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-tglb2/igt@kms_async_flips@alternate-sync-async-flip.html

  * igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-untiled:
    - shard-glk:          [FAIL][92] ([i915#3451]) -> [PASS][93]
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-glk6/igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-untiled.html
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-glk6/igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-untiled.html

  * igt@kms_flip@flip-vs-suspend-interruptible@c-dp1:
    - shard-apl:          [DMESG-WARN][94] ([i915#180]) -> [PASS][95] +1 similar issue
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-apl2/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl1/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible@b-dp1:
    - shard-kbl:          [FAIL][96] ([i915#2122]) -> [PASS][97]
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-kbl3/igt@kms_flip@plain-flip-fb-recreate-interruptible@b-dp1.html
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-kbl1/igt@kms_flip@plain-flip-fb-recreate-interruptible@b-dp1.html

  * igt@kms_psr@psr2_primary_page_flip:
    - shard-iclb:         [SKIP][98] ([fdo#109441]) -> [PASS][99] +1 similar issue
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-iclb5/igt@kms_psr@psr2_primary_page_flip.html
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html

  
#### Warnings ####

  * igt@gem_exec_fair@basic-pace@vcs0:
    - shard-kbl:          [FAIL][100] ([i915#2842]) -> [SKIP][101] ([fdo#109271])
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-kbl7/igt@gem_exec_fair@basic-pace@vcs0.html
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-kbl6/igt@gem_exec_fair@basic-pace@vcs0.html

  * igt@i915_pm_rc6_residency@rc6-fence:
    - shard-iclb:         [WARN][102] ([i915#2684]) -> [WARN][103] ([i915#1804] / [i915#2684])
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-iclb8/igt@i915_pm_rc6_residency@rc6-fence.html
   [103]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb4/igt@i915_pm_rc6_residency@rc6-fence.html

  * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-4:
    - shard-iclb:         [SKIP][104] ([i915#658]) -> [SKIP][105] ([i915#2920]) +2 similar issues
   [104]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-iclb3/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-4.html
   [105]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb2/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-4.html

  * igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1:
    - shard-iclb:         [SKIP][106] ([i915#2920]) -> [SKIP][107] ([i915#658])
   [106]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-iclb2/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1.html
   [107]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-iclb7/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1.html

  * igt@runner@aborted:
    - shard-apl:          ([FAIL][108], [FAIL][109], [FAIL][110]) ([i915#1610] / [i915#180] / [i915#1814] / [i915#3363]) -> ([FAIL][111], [FAIL][112]) ([i915#180] / [i915#3002] / [i915#3363])
   [108]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-apl8/igt@runner@aborted.html
   [109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-apl1/igt@runner@aborted.html
   [110]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-apl2/igt@runner@aborted.html
   [111]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl3/igt@runner@aborted.html
   [112]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-apl1/igt@runner@aborted.html
    - shard-glk:          ([FAIL][113], [FAIL][114]) ([i915#2722] / [i915#3002] / [i915#3363] / [k.org#202321]) -> ([FAIL][115], [FAIL][116]) ([i915#3002] / [i915#3363] / [k.org#202321])
   [113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-glk1/igt@runner@aborted.html
   [114]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10220/shard-glk8/igt@runner@aborted.html
   [115]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-glk9/igt@runner@aborted.html
   [116]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/shard-glk7/igt@runner@aborted.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#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109291]: https://bugs.freedesktop.org/show_bug.cgi?id=109291
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#110723]: https://bugs.freedesktop.org/show_bug.cgi?id=110723
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
  [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1099]: https://gitlab.freedesktop.org/drm/intel/issues/1099
  [i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
  [i915#1319]: https://gitlab.freedesktop.org/drm/intel/issues/1319
  [i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#1610]: https://gitlab.freedesktop.org/drm/intel/issues/1610
  [i915#1769]: https://gitlab.freedesktop.org/drm/intel/issues/1769
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#1804]: https://gitlab.freedesktop.org/drm/intel/issues/1804
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#2055]: https://gitlab.freedesktop.org/drm/intel/issues/2055
  [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2369]: https://gitlab.freedesktop.org/drm/intel/issues/2369
  [i915#2389]: https://gitlab.freedesktop.org/drm/intel/issues/2389
  [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
  [i915#2428]: https://gitlab.freedesktop.org/drm/intel/issues/2428
  [i915#2437]: https://gitlab.freedesktop.org/drm/intel/issues/2437
  [i915#2521]: https://gitlab.freedesktop.org/drm/intel/issues/2521
  [i915#2587]: https://gitlab.freedesktop.org/drm/intel/issues/2587
  [i915#2642]: https://gitlab.freedesktop.org/drm/intel/issues/2642
  [i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
  [i915#2684]: https://gitlab.freedesktop.org/drm/intel/issues/2684
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
  [i915#2849]: https://gitlab.freedesktop.org/drm/intel/issues/2849
  [i915#2868]: https://gitlab.freedesktop.org/drm/intel/issues/2868
  [i915#2920]: https://gitlab.freedesktop.org/drm/intel/issues/2920
  [i915#2994]: https://gitlab.freedesktop.org/drm/intel/issues/2994
  [i915#3002]: https://gitlab.freedesktop.org/drm/intel/issues/3002
  [i915#3063]: https://gitlab.freedesktop.org/drm/intel/issues/3063
  [i915#31]: https://gitlab.freedesktop.org/drm/intel/issues/31
  [i915#3318]: https://gitlab.freedesktop.org/drm/intel/issues/3318
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3451]: https://gitlab.freedesktop.org/drm/intel/issues/3451
  [i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
  [i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
  [k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321


Participating hosts (10 -> 7)
------------------------------

  Missing    (3): pig-skl-6260u pig-kbl-iris pig-glk-j5005 


Build changes
-------------

  * CI: CI-20190529 -> None
  * IGT: IGT_6105 -> IGTPW_5920
  * Piglit: piglit_4509 -> None

  CI-20190529: 20190529
  CI_DRM_10220: 1b77783fab8d920a675a3f6c8ee7de1eb206a19a @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_5920: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/index.html
  IGT_6105: 598a154680374e7875ae9ffc98425abc57398b2f @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5920/index.html

[-- Attachment #1.2: Type: text/html, Size: 35187 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.

[Petri Latvala]

On Mon, Jun 14, 2021 at 12:41:34PM -0400, Mark Yacoub wrote:
> Some devices such as amdgpu do not support imported buffers.
> Filter out those devices.
> Tested on Zork with chromeos-kernel-5_4.
> 
> Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
> ---
>  tests/kms_prime.c | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/kms_prime.c b/tests/kms_prime.c
> index 8cb2ca2a..480c7eb4 100644
> --- a/tests/kms_prime.c
> +++ b/tests/kms_prime.c
> @@ -249,6 +249,16 @@ static void test_crc(int exporter_fd, int importer_fd)
>  	igt_display_fini(&display);
>  }
>  
> +/* The test attempts to import the buffer object from one device to another.
> + * Filter out devices that aren't capable of doing this.
> + */
> +bool does_device_support_dmabuf_import(int fd) {
> +	/* AMDGPU uses VRAM. Any use of the fb will migrate it to VRAM, which is not sensible for
> +	 * an imported dma-buf.
> +	 */
> +	return !is_amdgpu_device(fd);
> +}

How is real (aka non-IGT) userspace supposed to handle this? Will they
need to check if the device is an AMD device before deciding whether
to import?

What happens in this test without this patch?

+Cc Arek. My initial impression for this is that the kernel should
take care of the idiosyncracies but I'm lacking the big picture.


-- 
Petri Latvala
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.

[Rodrigo Siqueira]

[-- Attachment #1.1: Type: text/plain, Size: 1813 bytes --]

Hi Alex and Christian,

This patch is related to prime, but I'm not familiar with this part of
our driver. Could you take a look at that?

Thanks

On 06/14, Mark Yacoub wrote:
> Some devices such as amdgpu do not support imported buffers.
> Filter out those devices.
> Tested on Zork with chromeos-kernel-5_4.
> 
> Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
> ---
>  tests/kms_prime.c | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/kms_prime.c b/tests/kms_prime.c
> index 8cb2ca2a..480c7eb4 100644
> --- a/tests/kms_prime.c
> +++ b/tests/kms_prime.c
> @@ -249,6 +249,16 @@ static void test_crc(int exporter_fd, int importer_fd)
>  	igt_display_fini(&display);
>  }
>  
> +/* The test attempts to import the buffer object from one device to another.
> + * Filter out devices that aren't capable of doing this.
> + */
> +bool does_device_support_dmabuf_import(int fd) {
> +	/* AMDGPU uses VRAM. Any use of the fb will migrate it to VRAM, which is not sensible for
> +	 * an imported dma-buf.
> +	 */
> +	return !is_amdgpu_device(fd);
> +}
> +
>  igt_main
>  {
>  	igt_fixture
> @@ -262,10 +272,10 @@ igt_main
>  
>  		/* ANY = anything that is not VGEM */
>  		first_fd = __drm_open_driver_another(0, DRIVER_ANY | DRIVER_VGEM);
> -		igt_require(first_fd >= 0);
> +		igt_require(first_fd >= 0 && does_device_support_dmabuf_import(first_fd));
>  
>  		second_fd = __drm_open_driver_another(1, DRIVER_ANY | DRIVER_VGEM);
> -		igt_require(second_fd >= 0);
> +		igt_require(second_fd >= 0 && does_device_support_dmabuf_import(second_fd));
>  
>  		if (has_prime_export(first_fd) &&
>  		    has_prime_import(second_fd))
> -- 
> 2.32.0.272.g935e593368-goog
> 

-- 
Rodrigo Siqueira
https://siqueira.tech

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.

[Christian König]

Hi guys,

first of all thanks Rodrigo for bringing this to my attention.

Mark, as the DMA-buf maintainer I unfortunately have to reject this patch.

Direct scanout from imported surfaces is not something supported with 
DMA-buf in general at the moment.

We do have some support for this between AMD GPUs in A+A laptops, and it 
might work with i915 and some of the drivers used on ARM.

But all of this is completely vendor specific since there are some very 
low level and hardware specific limitations to take account into.

Regards,
Christian.

Am 15.06.21 um 15:12 schrieb Rodrigo Siqueira:
> Hi Alex and Christian,
>
> This patch is related to prime, but I'm not familiar with this part of
> our driver. Could you take a look at that?
>
> Thanks
>
> On 06/14, Mark Yacoub wrote:
>> Some devices such as amdgpu do not support imported buffers.
>> Filter out those devices.
>> Tested on Zork with chromeos-kernel-5_4.
>>
>> Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
>> ---
>>   tests/kms_prime.c | 14 ++++++++++++--
>>   1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/tests/kms_prime.c b/tests/kms_prime.c
>> index 8cb2ca2a..480c7eb4 100644
>> --- a/tests/kms_prime.c
>> +++ b/tests/kms_prime.c
>> @@ -249,6 +249,16 @@ static void test_crc(int exporter_fd, int importer_fd)
>>   	igt_display_fini(&display);
>>   }
>>   
>> +/* The test attempts to import the buffer object from one device to another.
>> + * Filter out devices that aren't capable of doing this.
>> + */
>> +bool does_device_support_dmabuf_import(int fd) {
>> +	/* AMDGPU uses VRAM. Any use of the fb will migrate it to VRAM, which is not sensible for
>> +	 * an imported dma-buf.
>> +	 */
>> +	return !is_amdgpu_device(fd);
>> +}
>> +
>>   igt_main
>>   {
>>   	igt_fixture
>> @@ -262,10 +272,10 @@ igt_main
>>   
>>   		/* ANY = anything that is not VGEM */
>>   		first_fd = __drm_open_driver_another(0, DRIVER_ANY | DRIVER_VGEM);
>> -		igt_require(first_fd >= 0);
>> +		igt_require(first_fd >= 0 && does_device_support_dmabuf_import(first_fd));
>>   
>>   		second_fd = __drm_open_driver_another(1, DRIVER_ANY | DRIVER_VGEM);
>> -		igt_require(second_fd >= 0);
>> +		igt_require(second_fd >= 0 && does_device_support_dmabuf_import(second_fd));
>>   
>>   		if (has_prime_export(first_fd) &&
>>   		    has_prime_import(second_fd))
>> -- 
>> 2.32.0.272.g935e593368-goog
>>

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.

[Mark Yacoub]

On Tue, Jun 15, 2021 at 5:03 AM Petri Latvala <petri.latvala@intel.com> wrote:
>
> On Mon, Jun 14, 2021 at 12:41:34PM -0400, Mark Yacoub wrote:
> > Some devices such as amdgpu do not support imported buffers.
> > Filter out those devices.
> > Tested on Zork with chromeos-kernel-5_4.
> >
> > Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
> > ---
> >  tests/kms_prime.c | 14 ++++++++++++--
> >  1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/tests/kms_prime.c b/tests/kms_prime.c
> > index 8cb2ca2a..480c7eb4 100644
> > --- a/tests/kms_prime.c
> > +++ b/tests/kms_prime.c
> > @@ -249,6 +249,16 @@ static void test_crc(int exporter_fd, int importer_fd)
> >       igt_display_fini(&display);
> >  }
> >
> > +/* The test attempts to import the buffer object from one device to another.
> > + * Filter out devices that aren't capable of doing this.
> > + */
> > +bool does_device_support_dmabuf_import(int fd) {
> > +     /* AMDGPU uses VRAM. Any use of the fb will migrate it to VRAM, which is not sensible for
> > +      * an imported dma-buf.
> > +      */
> > +     return !is_amdgpu_device(fd);
> > +}
>
> How is real (aka non-IGT) userspace supposed to handle this? Will they
> need to check if the device is an AMD device before deciding whether
> to import?
>
> What happens in this test without this patch?
amdgpu fails to create a framebuffer if the drm_gem_object has a valid
`import_attach` property.
>
> +Cc Arek. My initial impression for this is that the kernel should
> take care of the idiosyncracies but I'm lacking the big picture.
>
>
> --
> Petri Latvala
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.

[Mark Yacoub]

On Tue, Jun 15, 2021 at 9:43 AM Christian König
<christian.koenig@amd.com> wrote:
>
> Hi guys,
>
> first of all thanks Rodrigo for bringing this to my attention.
>
> Mark, as the DMA-buf maintainer I unfortunately have to reject this patch.
This test is currently running on i915, but fails on amdgpu due to the
check of `import_attach` (this is the commit that introduced the
change: https://gitlab.freedesktop.org/agd5f/linux/-/commit/1769152ac64b0b07583f696b621624df2ca4c840)
What do you recommend instead?
>
> Direct scanout from imported surfaces is not something supported with
> DMA-buf in general at the moment.
Do you mean the problem is in the test itself?
>
> We do have some support for this between AMD GPUs in A+A laptops, and it
> might work with i915 and some of the drivers used on ARM.
>
> But all of this is completely vendor specific since there are some very
> low level and hardware specific limitations to take account into.
>
> Regards,
> Christian.
>
> Am 15.06.21 um 15:12 schrieb Rodrigo Siqueira:
> > Hi Alex and Christian,
> >
> > This patch is related to prime, but I'm not familiar with this part of
> > our driver. Could you take a look at that?
> >
> > Thanks
> >
> > On 06/14, Mark Yacoub wrote:
> >> Some devices such as amdgpu do not support imported buffers.
> >> Filter out those devices.
> >> Tested on Zork with chromeos-kernel-5_4.
> >>
> >> Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
> >> ---
> >>   tests/kms_prime.c | 14 ++++++++++++--
> >>   1 file changed, 12 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/tests/kms_prime.c b/tests/kms_prime.c
> >> index 8cb2ca2a..480c7eb4 100644
> >> --- a/tests/kms_prime.c
> >> +++ b/tests/kms_prime.c
> >> @@ -249,6 +249,16 @@ static void test_crc(int exporter_fd, int importer_fd)
> >>      igt_display_fini(&display);
> >>   }
> >>
> >> +/* The test attempts to import the buffer object from one device to another.
> >> + * Filter out devices that aren't capable of doing this.
> >> + */
> >> +bool does_device_support_dmabuf_import(int fd) {
> >> +    /* AMDGPU uses VRAM. Any use of the fb will migrate it to VRAM, which is not sensible for
> >> +     * an imported dma-buf.
> >> +     */
> >> +    return !is_amdgpu_device(fd);
> >> +}
> >> +
> >>   igt_main
> >>   {
> >>      igt_fixture
> >> @@ -262,10 +272,10 @@ igt_main
> >>
> >>              /* ANY = anything that is not VGEM */
> >>              first_fd = __drm_open_driver_another(0, DRIVER_ANY | DRIVER_VGEM);
> >> -            igt_require(first_fd >= 0);
> >> +            igt_require(first_fd >= 0 && does_device_support_dmabuf_import(first_fd));
> >>
> >>              second_fd = __drm_open_driver_another(1, DRIVER_ANY | DRIVER_VGEM);
> >> -            igt_require(second_fd >= 0);
> >> +            igt_require(second_fd >= 0 && does_device_support_dmabuf_import(second_fd));
> >>
> >>              if (has_prime_export(first_fd) &&
> >>                  has_prime_import(second_fd))
> >> --
> >> 2.32.0.272.g935e593368-goog
> >>
>
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.

[Christian König]

Hi Petri,

Am 15.06.21 um 16:46 schrieb Mark Yacoub:
> On Tue, Jun 15, 2021 at 5:03 AM Petri Latvala <petri.latvala@intel.com> wrote:
>> On Mon, Jun 14, 2021 at 12:41:34PM -0400, Mark Yacoub wrote:
>>> Some devices such as amdgpu do not support imported buffers.
>>> Filter out those devices.
>>> Tested on Zork with chromeos-kernel-5_4.
>>>
>>> Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
>>> ---
>>>   tests/kms_prime.c | 14 ++++++++++++--
>>>   1 file changed, 12 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/tests/kms_prime.c b/tests/kms_prime.c
>>> index 8cb2ca2a..480c7eb4 100644
>>> --- a/tests/kms_prime.c
>>> +++ b/tests/kms_prime.c
>>> @@ -249,6 +249,16 @@ static void test_crc(int exporter_fd, int importer_fd)
>>>        igt_display_fini(&display);
>>>   }
>>>
>>> +/* The test attempts to import the buffer object from one device to another.
>>> + * Filter out devices that aren't capable of doing this.
>>> + */
>>> +bool does_device_support_dmabuf_import(int fd) {
>>> +     /* AMDGPU uses VRAM. Any use of the fb will migrate it to VRAM, which is not sensible for
>>> +      * an imported dma-buf.
>>> +      */
>>> +     return !is_amdgpu_device(fd);
>>> +}
>> How is real (aka non-IGT) userspace supposed to handle this? Will they
>> need to check if the device is an AMD device before deciding whether
>> to import?
>>
>> What happens in this test without this patch?
> amdgpu fails to create a framebuffer if the drm_gem_object has a valid
> `import_attach` property.
>> +Cc Arek. My initial impression for this is that the kernel should
>> take care of the idiosyncracies but I'm lacking the big picture.

Using DMA-buf imported buffer objects as scanout is in general vendor 
specific.

In other words failing to create a framebuffer is the normal reaction here.

Only AMD GPUs in some hardware variants, probably some ARM SOCs and 
maybe i915 can handle that. All other drivers should fail here.

The general approach should be to try to create a framebuffer and if 
that doesn't work use a fallback mechanism.

Regards,
Christian.

>>
>>
>> --
>> Petri Latvala

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.

[Christian König]

Am 15.06.21 um 16:49 schrieb Mark Yacoub:
> On Tue, Jun 15, 2021 at 9:43 AM Christian König
> <christian.koenig@amd.com> wrote:
>> Hi guys,
>>
>> first of all thanks Rodrigo for bringing this to my attention.
>>
>> Mark, as the DMA-buf maintainer I unfortunately have to reject this patch.
> This test is currently running on i915, but fails on amdgpu due to the
> check of `import_attach` (this is the commit that introduced the
> change: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fagd5f%2Flinux%2F-%2Fcommit%2F1769152ac64b0b07583f696b621624df2ca4c840&amp;data=04%7C01%7Cchristian.koenig%40amd.com%7Cbdc7b671688747b5b28808d9300ccce7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637593653819504079%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Nwdst2UNrAZXViQoXowcxzJxHGz0ktuX3OIFLESoEoo%3D&amp;reserved=0)
> What do you recommend instead?

Dropping the test from the general KMS tests. Scanning out from imported 
DMA-bufs is completely vendor specific.

>> Direct scanout from imported surfaces is not something supported with
>> DMA-buf in general at the moment.
> Do you mean the problem is in the test itself?

Yes, exactly. Testing that without checking for vendor specific support 
is utterly nonsense.

I'm pretty sure that this is not even fully supported by i915. Daniel 
Vetter and I chatted about stuff like that a while ago and he mentioned 
that i915 similar to AMD GPUs have some rather strict hardware 
requirements which are currently not expressible with DMA-buf.

I'm not sure about other drivers, but my guess is that none of them will 
actually support this.

Regards,
Christian.

>> We do have some support for this between AMD GPUs in A+A laptops, and it
>> might work with i915 and some of the drivers used on ARM.
>>
>> But all of this is completely vendor specific since there are some very
>> low level and hardware specific limitations to take account into.
>>
>> Regards,
>> Christian.
>>
>> Am 15.06.21 um 15:12 schrieb Rodrigo Siqueira:
>>> Hi Alex and Christian,
>>>
>>> This patch is related to prime, but I'm not familiar with this part of
>>> our driver. Could you take a look at that?
>>>
>>> Thanks
>>>
>>> On 06/14, Mark Yacoub wrote:
>>>> Some devices such as amdgpu do not support imported buffers.
>>>> Filter out those devices.
>>>> Tested on Zork with chromeos-kernel-5_4.
>>>>
>>>> Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
>>>> ---
>>>>    tests/kms_prime.c | 14 ++++++++++++--
>>>>    1 file changed, 12 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/tests/kms_prime.c b/tests/kms_prime.c
>>>> index 8cb2ca2a..480c7eb4 100644
>>>> --- a/tests/kms_prime.c
>>>> +++ b/tests/kms_prime.c
>>>> @@ -249,6 +249,16 @@ static void test_crc(int exporter_fd, int importer_fd)
>>>>       igt_display_fini(&display);
>>>>    }
>>>>
>>>> +/* The test attempts to import the buffer object from one device to another.
>>>> + * Filter out devices that aren't capable of doing this.
>>>> + */
>>>> +bool does_device_support_dmabuf_import(int fd) {
>>>> +    /* AMDGPU uses VRAM. Any use of the fb will migrate it to VRAM, which is not sensible for
>>>> +     * an imported dma-buf.
>>>> +     */
>>>> +    return !is_amdgpu_device(fd);
>>>> +}
>>>> +
>>>>    igt_main
>>>>    {
>>>>       igt_fixture
>>>> @@ -262,10 +272,10 @@ igt_main
>>>>
>>>>               /* ANY = anything that is not VGEM */
>>>>               first_fd = __drm_open_driver_another(0, DRIVER_ANY | DRIVER_VGEM);
>>>> -            igt_require(first_fd >= 0);
>>>> +            igt_require(first_fd >= 0 && does_device_support_dmabuf_import(first_fd));
>>>>
>>>>               second_fd = __drm_open_driver_another(1, DRIVER_ANY | DRIVER_VGEM);
>>>> -            igt_require(second_fd >= 0);
>>>> +            igt_require(second_fd >= 0 && does_device_support_dmabuf_import(second_fd));
>>>>
>>>>               if (has_prime_export(first_fd) &&
>>>>                   has_prime_import(second_fd))
>>>> --
>>>> 2.32.0.272.g935e593368-goog
>>>>

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.

[Mark Yacoub]

@Petri Latvala would it make sense that I go ahead and move this test to i915?

On Tue, Jun 15, 2021 at 10:55 AM Christian König
<christian.koenig@amd.com> wrote:
>
> Am 15.06.21 um 16:49 schrieb Mark Yacoub:
> > On Tue, Jun 15, 2021 at 9:43 AM Christian König
> > <christian.koenig@amd.com> wrote:
> >> Hi guys,
> >>
> >> first of all thanks Rodrigo for bringing this to my attention.
> >>
> >> Mark, as the DMA-buf maintainer I unfortunately have to reject this patch.
> > This test is currently running on i915, but fails on amdgpu due to the
> > check of `import_attach` (this is the commit that introduced the
> > change: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fagd5f%2Flinux%2F-%2Fcommit%2F1769152ac64b0b07583f696b621624df2ca4c840&amp;data=04%7C01%7Cchristian.koenig%40amd.com%7Cbdc7b671688747b5b28808d9300ccce7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637593653819504079%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Nwdst2UNrAZXViQoXowcxzJxHGz0ktuX3OIFLESoEoo%3D&amp;reserved=0)
> > What do you recommend instead?
>
> Dropping the test from the general KMS tests. Scanning out from imported
> DMA-bufs is completely vendor specific.
>
> >> Direct scanout from imported surfaces is not something supported with
> >> DMA-buf in general at the moment.
> > Do you mean the problem is in the test itself?
>
> Yes, exactly. Testing that without checking for vendor specific support
> is utterly nonsense.
>
> I'm pretty sure that this is not even fully supported by i915. Daniel
> Vetter and I chatted about stuff like that a while ago and he mentioned
> that i915 similar to AMD GPUs have some rather strict hardware
> requirements which are currently not expressible with DMA-buf.
>
> I'm not sure about other drivers, but my guess is that none of them will
> actually support this.
>
> Regards,
> Christian.
>
> >> We do have some support for this between AMD GPUs in A+A laptops, and it
> >> might work with i915 and some of the drivers used on ARM.
> >>
> >> But all of this is completely vendor specific since there are some very
> >> low level and hardware specific limitations to take account into.
> >>
> >> Regards,
> >> Christian.
> >>
> >> Am 15.06.21 um 15:12 schrieb Rodrigo Siqueira:
> >>> Hi Alex and Christian,
> >>>
> >>> This patch is related to prime, but I'm not familiar with this part of
> >>> our driver. Could you take a look at that?
> >>>
> >>> Thanks
> >>>
> >>> On 06/14, Mark Yacoub wrote:
> >>>> Some devices such as amdgpu do not support imported buffers.
> >>>> Filter out those devices.
> >>>> Tested on Zork with chromeos-kernel-5_4.
> >>>>
> >>>> Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
> >>>> ---
> >>>>    tests/kms_prime.c | 14 ++++++++++++--
> >>>>    1 file changed, 12 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/tests/kms_prime.c b/tests/kms_prime.c
> >>>> index 8cb2ca2a..480c7eb4 100644
> >>>> --- a/tests/kms_prime.c
> >>>> +++ b/tests/kms_prime.c
> >>>> @@ -249,6 +249,16 @@ static void test_crc(int exporter_fd, int importer_fd)
> >>>>       igt_display_fini(&display);
> >>>>    }
> >>>>
> >>>> +/* The test attempts to import the buffer object from one device to another.
> >>>> + * Filter out devices that aren't capable of doing this.
> >>>> + */
> >>>> +bool does_device_support_dmabuf_import(int fd) {
> >>>> +    /* AMDGPU uses VRAM. Any use of the fb will migrate it to VRAM, which is not sensible for
> >>>> +     * an imported dma-buf.
> >>>> +     */
> >>>> +    return !is_amdgpu_device(fd);
> >>>> +}
> >>>> +
> >>>>    igt_main
> >>>>    {
> >>>>       igt_fixture
> >>>> @@ -262,10 +272,10 @@ igt_main
> >>>>
> >>>>               /* ANY = anything that is not VGEM */
> >>>>               first_fd = __drm_open_driver_another(0, DRIVER_ANY | DRIVER_VGEM);
> >>>> -            igt_require(first_fd >= 0);
> >>>> +            igt_require(first_fd >= 0 && does_device_support_dmabuf_import(first_fd));
> >>>>
> >>>>               second_fd = __drm_open_driver_another(1, DRIVER_ANY | DRIVER_VGEM);
> >>>> -            igt_require(second_fd >= 0);
> >>>> +            igt_require(second_fd >= 0 && does_device_support_dmabuf_import(second_fd));
> >>>>
> >>>>               if (has_prime_export(first_fd) &&
> >>>>                   has_prime_import(second_fd))
> >>>> --
> >>>> 2.32.0.272.g935e593368-goog
> >>>>
>
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.

[Christian König]

The alternative would be to try to create a framebuffer, but don't take 
it as a failure when that fails with the correct return code.

Christian.

Am 15.06.21 um 17:46 schrieb Mark Yacoub:
> @Petri Latvala would it make sense that I go ahead and move this test to i915?
>
> On Tue, Jun 15, 2021 at 10:55 AM Christian König
> <christian.koenig@amd.com> wrote:
>> Am 15.06.21 um 16:49 schrieb Mark Yacoub:
>>> On Tue, Jun 15, 2021 at 9:43 AM Christian König
>>> <christian.koenig@amd.com> wrote:
>>>> Hi guys,
>>>>
>>>> first of all thanks Rodrigo for bringing this to my attention.
>>>>
>>>> Mark, as the DMA-buf maintainer I unfortunately have to reject this patch.
>>> This test is currently running on i915, but fails on amdgpu due to the
>>> check of `import_attach` (this is the commit that introduced the
>>> change: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fagd5f%2Flinux%2F-%2Fcommit%2F1769152ac64b0b07583f696b621624df2ca4c840&amp;data=04%7C01%7Cchristian.koenig%40amd.com%7Cee404ba949124914936808d93014d4ef%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637593688314449415%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=qFUa24zx9I1ku%2FuRo4eFEQ4Ky0CbGoeo4VBe1HQMtBc%3D&amp;reserved=0)
>>> What do you recommend instead?
>> Dropping the test from the general KMS tests. Scanning out from imported
>> DMA-bufs is completely vendor specific.
>>
>>>> Direct scanout from imported surfaces is not something supported with
>>>> DMA-buf in general at the moment.
>>> Do you mean the problem is in the test itself?
>> Yes, exactly. Testing that without checking for vendor specific support
>> is utterly nonsense.
>>
>> I'm pretty sure that this is not even fully supported by i915. Daniel
>> Vetter and I chatted about stuff like that a while ago and he mentioned
>> that i915 similar to AMD GPUs have some rather strict hardware
>> requirements which are currently not expressible with DMA-buf.
>>
>> I'm not sure about other drivers, but my guess is that none of them will
>> actually support this.
>>
>> Regards,
>> Christian.
>>
>>>> We do have some support for this between AMD GPUs in A+A laptops, and it
>>>> might work with i915 and some of the drivers used on ARM.
>>>>
>>>> But all of this is completely vendor specific since there are some very
>>>> low level and hardware specific limitations to take account into.
>>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>> Am 15.06.21 um 15:12 schrieb Rodrigo Siqueira:
>>>>> Hi Alex and Christian,
>>>>>
>>>>> This patch is related to prime, but I'm not familiar with this part of
>>>>> our driver. Could you take a look at that?
>>>>>
>>>>> Thanks
>>>>>
>>>>> On 06/14, Mark Yacoub wrote:
>>>>>> Some devices such as amdgpu do not support imported buffers.
>>>>>> Filter out those devices.
>>>>>> Tested on Zork with chromeos-kernel-5_4.
>>>>>>
>>>>>> Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
>>>>>> ---
>>>>>>     tests/kms_prime.c | 14 ++++++++++++--
>>>>>>     1 file changed, 12 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/tests/kms_prime.c b/tests/kms_prime.c
>>>>>> index 8cb2ca2a..480c7eb4 100644
>>>>>> --- a/tests/kms_prime.c
>>>>>> +++ b/tests/kms_prime.c
>>>>>> @@ -249,6 +249,16 @@ static void test_crc(int exporter_fd, int importer_fd)
>>>>>>        igt_display_fini(&display);
>>>>>>     }
>>>>>>
>>>>>> +/* The test attempts to import the buffer object from one device to another.
>>>>>> + * Filter out devices that aren't capable of doing this.
>>>>>> + */
>>>>>> +bool does_device_support_dmabuf_import(int fd) {
>>>>>> +    /* AMDGPU uses VRAM. Any use of the fb will migrate it to VRAM, which is not sensible for
>>>>>> +     * an imported dma-buf.
>>>>>> +     */
>>>>>> +    return !is_amdgpu_device(fd);
>>>>>> +}
>>>>>> +
>>>>>>     igt_main
>>>>>>     {
>>>>>>        igt_fixture
>>>>>> @@ -262,10 +272,10 @@ igt_main
>>>>>>
>>>>>>                /* ANY = anything that is not VGEM */
>>>>>>                first_fd = __drm_open_driver_another(0, DRIVER_ANY | DRIVER_VGEM);
>>>>>> -            igt_require(first_fd >= 0);
>>>>>> +            igt_require(first_fd >= 0 && does_device_support_dmabuf_import(first_fd));
>>>>>>
>>>>>>                second_fd = __drm_open_driver_another(1, DRIVER_ANY | DRIVER_VGEM);
>>>>>> -            igt_require(second_fd >= 0);
>>>>>> +            igt_require(second_fd >= 0 && does_device_support_dmabuf_import(second_fd));
>>>>>>
>>>>>>                if (has_prime_export(first_fd) &&
>>>>>>                    has_prime_import(second_fd))
>>>>>> --
>>>>>> 2.32.0.272.g935e593368-goog
>>>>>>

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.

[Petri Latvala]

On Tue, Jun 15, 2021 at 06:20:23PM +0200, Christian König wrote:
> The alternative would be to try to create a framebuffer, but don't take it
> as a failure when that fails with the correct return code.

This.

If the importing can fail for documented reasons, we should just add
code that checks that the error is the documented one and then
igt_skip(), fail the test if it's something it shouldn't.

As a general rule the tests goes to hardware specific subdirs if the
interface tested is hardware-specific. This interface is not, just the
behaviour.


-- 
Petri Latvala
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.

[Christian König]

Am 16.06.21 um 09:34 schrieb Petri Latvala:
> On Tue, Jun 15, 2021 at 06:20:23PM +0200, Christian König wrote:
>> The alternative would be to try to create a framebuffer, but don't take it
>> as a failure when that fails with the correct return code.
> This.
>
> If the importing can fail for documented reasons, we should just add
> code that checks that the error is the documented one and then
> igt_skip(), fail the test if it's something it shouldn't.

Good point, but I don't think that this behavior is well documented 
anywhere.

I'm also pretty sure that most drivers don't correctly reject an 
imported DMA-buf for scanout when the hardware can't do this. Resulting 
in either just garbage on the screen or a lockup.

Exercising this in an unit tests is probably a good idea, but only after 
auditing all drivers for correct behavior.

Regards,
Christian.

> As a general rule the tests goes to hardware specific subdirs if the
> interface tested is hardware-specific. This interface is not, just the
> behaviour.

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.

[Petri Latvala]

On Wed, Jun 16, 2021 at 10:07:18AM +0200, Christian König wrote:
> 
> 
> Am 16.06.21 um 09:34 schrieb Petri Latvala:
> > On Tue, Jun 15, 2021 at 06:20:23PM +0200, Christian König wrote:
> > > The alternative would be to try to create a framebuffer, but don't take it
> > > as a failure when that fails with the correct return code.
> > This.
> > 
> > If the importing can fail for documented reasons, we should just add
> > code that checks that the error is the documented one and then
> > igt_skip(), fail the test if it's something it shouldn't.
> 
> Good point, but I don't think that this behavior is well documented
> anywhere.
> 
> I'm also pretty sure that most drivers don't correctly reject an imported
> DMA-buf for scanout when the hardware can't do this. Resulting in either
> just garbage on the screen or a lockup.
> 
> Exercising this in an unit tests is probably a good idea, but only after
> auditing all drivers for correct behavior.

The thing is, having a test for it is the best method of auditing and
being _sure_.

Being able to lockup devices with an operation that doesn't even
require root (?) sounds... slightly bad.


-- 
Petri Latvala
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.

[Christian König]

Am 16.06.21 um 10:46 schrieb Petri Latvala:
> On Wed, Jun 16, 2021 at 10:07:18AM +0200, Christian König wrote:
>>
>> Am 16.06.21 um 09:34 schrieb Petri Latvala:
>>> On Tue, Jun 15, 2021 at 06:20:23PM +0200, Christian König wrote:
>>>> The alternative would be to try to create a framebuffer, but don't take it
>>>> as a failure when that fails with the correct return code.
>>> This.
>>>
>>> If the importing can fail for documented reasons, we should just add
>>> code that checks that the error is the documented one and then
>>> igt_skip(), fail the test if it's something it shouldn't.
>> Good point, but I don't think that this behavior is well documented
>> anywhere.
>>
>> I'm also pretty sure that most drivers don't correctly reject an imported
>> DMA-buf for scanout when the hardware can't do this. Resulting in either
>> just garbage on the screen or a lockup.
>>
>> Exercising this in an unit tests is probably a good idea, but only after
>> auditing all drivers for correct behavior.
> The thing is, having a test for it is the best method of auditing and
> being _sure_.

Ok, yeah that is a really good argument as well.

> Being able to lockup devices with an operation that doesn't even
> require root (?) sounds... slightly bad.

Well a bit more than slightly bad I would say :)

First we added the extra check to amdgpu because we found screen garbage 
on dGPUs. When we then later implemented scanout from imported DMA-bufs 
for APUs we found that a certain combination of IOMMU enabled, 
resolution and refresh rate could hard lock the PCIe root complex.

It's absolutely not nice if even serial consoles or network consoles 
don't give you any hint on what's going wrong.

I also think we should keep this test case around, just don't be 
surprised if people start to scream because it hard lock their systems.

Regards,
Christian.
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.

[Daniel Vetter]

On Wed, Jun 16, 2021 at 11:08 AM Christian König
<christian.koenig@amd.com> wrote:
>
> Am 16.06.21 um 10:46 schrieb Petri Latvala:
> > On Wed, Jun 16, 2021 at 10:07:18AM +0200, Christian König wrote:
> >>
> >> Am 16.06.21 um 09:34 schrieb Petri Latvala:
> >>> On Tue, Jun 15, 2021 at 06:20:23PM +0200, Christian König wrote:
> >>>> The alternative would be to try to create a framebuffer, but don't take it
> >>>> as a failure when that fails with the correct return code.
> >>> This.
> >>>
> >>> If the importing can fail for documented reasons, we should just add
> >>> code that checks that the error is the documented one and then
> >>> igt_skip(), fail the test if it's something it shouldn't.
> >> Good point, but I don't think that this behavior is well documented
> >> anywhere.
> >>
> >> I'm also pretty sure that most drivers don't correctly reject an imported
> >> DMA-buf for scanout when the hardware can't do this. Resulting in either
> >> just garbage on the screen or a lockup.
> >>
> >> Exercising this in an unit tests is probably a good idea, but only after
> >> auditing all drivers for correct behavior.
> > The thing is, having a test for it is the best method of auditing and
> > being _sure_.
>
> Ok, yeah that is a really good argument as well.

Also ideally we pull in a few more compositor folks into the
discussion, and then make sure that the ADDFB kernel documentation is
updated accordingly. Atm it doesn't even really exist, our uapi docs
are a bit bare-bones, but we got to start somewhere.

Also this could already fail at the FD2HANDLE stage in many cases.
E.g. kms-only drivers generally have their "can I scan this out" tests
there, but drivers with kms+render can only check for "can I use this
at all" in FD2HANDLE, and need to delegate "can I scan this out" to
ADDFB.

When we've nailed all that, i.e. igt tests that we agree on and
documented kernel behaviour, then I think this kind of stuff should be
a generic test.

> > Being able to lockup devices with an operation that doesn't even
> > require root (?) sounds... slightly bad.
>
> Well a bit more than slightly bad I would say :)
>
> First we added the extra check to amdgpu because we found screen garbage
> on dGPUs. When we then later implemented scanout from imported DMA-bufs
> for APUs we found that a certain combination of IOMMU enabled,
> resolution and refresh rate could hard lock the PCIe root complex.
>
> It's absolutely not nice if even serial consoles or network consoles
> don't give you any hint on what's going wrong.
>
> I also think we should keep this test case around, just don't be
> surprised if people start to scream because it hard lock their systems.

That sounds like driver bugs to me, but also don't get me started on
hardlocking the box because the scanout block hogs the memory
controller :-)

btw the special drivers are not i915, i915 can pretty much scan out
anything that's in system memory as a igpu (if it's the right format
and alignment ofc). dgpu needs vram. but there's definitely a lot of
igpu that have very special needs indeed and can both fail ad
FD2HANDLE and ADDFB stage for a given buffer simply due to the backing
storage.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev