* [igt-dev] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting @ 2019-11-04 20:17 ` Chris Wilson 0 siblings, 0 replies; 17+ messages in thread From: Chris Wilson @ 2019-11-04 20:17 UTC (permalink / raw) To: intel-gfx; +Cc: igt-dev, Tvrtko Ursulin As the scratch buf is shared between the two requests on both engines, we need to wait for both to finish using the buffer before we reset it. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> --- tests/i915/gem_exec_balancer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c index e52f5df95..70c4529b4 100644 --- a/tests/i915/gem_exec_balancer.c +++ b/tests/i915/gem_exec_balancer.c @@ -840,7 +840,7 @@ static void bonded_slice(int i915) gem_execbuf(i915, &eb); close(eb.rsvd2); - gem_sync(i915, obj[2].handle); + gem_sync(i915, obj[0].handle); } *stop = 1; -- 2.24.0 _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting @ 2019-11-04 20:17 ` Chris Wilson 0 siblings, 0 replies; 17+ messages in thread From: Chris Wilson @ 2019-11-04 20:17 UTC (permalink / raw) To: intel-gfx; +Cc: igt-dev As the scratch buf is shared between the two requests on both engines, we need to wait for both to finish using the buffer before we reset it. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> --- tests/i915/gem_exec_balancer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c index e52f5df95..70c4529b4 100644 --- a/tests/i915/gem_exec_balancer.c +++ b/tests/i915/gem_exec_balancer.c @@ -840,7 +840,7 @@ static void bonded_slice(int i915) gem_execbuf(i915, &eb); close(eb.rsvd2); - gem_sync(i915, obj[2].handle); + gem_sync(i915, obj[0].handle); } *stop = 1; -- 2.24.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting @ 2019-11-04 20:17 ` Chris Wilson 0 siblings, 0 replies; 17+ messages in thread From: Chris Wilson @ 2019-11-04 20:17 UTC (permalink / raw) To: intel-gfx; +Cc: igt-dev As the scratch buf is shared between the two requests on both engines, we need to wait for both to finish using the buffer before we reset it. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> --- tests/i915/gem_exec_balancer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c index e52f5df95..70c4529b4 100644 --- a/tests/i915/gem_exec_balancer.c +++ b/tests/i915/gem_exec_balancer.c @@ -840,7 +840,7 @@ static void bonded_slice(int i915) gem_execbuf(i915, &eb); close(eb.rsvd2); - gem_sync(i915, obj[2].handle); + gem_sync(i915, obj[0].handle); } *stop = 1; -- 2.24.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [igt-dev] ✓ Fi.CI.BAT: success for i915/gem_exec_balancer: Wait for both engines to complete before resubmitting 2019-11-04 20:17 ` Chris Wilson (?) (?) @ 2019-11-04 20:57 ` Patchwork -1 siblings, 0 replies; 17+ messages in thread From: Patchwork @ 2019-11-04 20:57 UTC (permalink / raw) To: Chris Wilson; +Cc: igt-dev == Series Details == Series: i915/gem_exec_balancer: Wait for both engines to complete before resubmitting URL : https://patchwork.freedesktop.org/series/68966/ State : success == Summary == CI Bug Log - changes from CI_DRM_7258 -> IGTPW_3648 ==================================================== Summary ------- **WARNING** Minor unknown changes coming with IGTPW_3648 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in IGTPW_3648, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/index.html Possible new issues ------------------- Here are the unknown changes that may have been introduced in IGTPW_3648: ### IGT changes ### #### Warnings #### * igt@i915_pm_rpm@basic-rte: - fi-kbl-guc: [SKIP][1] ([fdo#109271]) -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-kbl-guc/igt@i915_pm_rpm@basic-rte.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/fi-kbl-guc/igt@i915_pm_rpm@basic-rte.html Known issues ------------ Here are the changes found in IGTPW_3648 that come from known issues: ### IGT changes ### #### Issues hit #### * igt@gem_flink_basic@flink-lifetime: - fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-icl-u3/igt@gem_flink_basic@flink-lifetime.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/fi-icl-u3/igt@gem_flink_basic@flink-lifetime.html * igt@i915_selftest@live_blt: - fi-bsw-n3050: [PASS][5] -> [DMESG-FAIL][6] ([fdo#112176]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-bsw-n3050/igt@i915_selftest@live_blt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/fi-bsw-n3050/igt@i915_selftest@live_blt.html * igt@kms_busy@basic-flip-a: - fi-icl-u2: [PASS][7] -> [TIMEOUT][8] ([fdo#111800]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-icl-u2/igt@kms_busy@basic-flip-a.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/fi-icl-u2/igt@kms_busy@basic-flip-a.html #### Possible fixes #### * {igt@gem_exec_suspend@basic-s0}: - fi-bsw-kefka: [DMESG-WARN][9] ([fdo#112120]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-bsw-kefka/igt@gem_exec_suspend@basic-s0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/fi-bsw-kefka/igt@gem_exec_suspend@basic-s0.html * igt@gem_flink_basic@basic: - fi-icl-u3: [DMESG-WARN][11] ([fdo#107724] / [fdo#112052 ]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-icl-u3/igt@gem_flink_basic@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/fi-icl-u3/igt@gem_flink_basic@basic.html * igt@prime_busy@basic-before-default: - fi-icl-u3: [DMESG-WARN][13] ([fdo#107724]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-icl-u3/igt@prime_busy@basic-before-default.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/fi-icl-u3/igt@prime_busy@basic-before-default.html #### Warnings #### * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][15] ([fdo#111407]) -> [FAIL][16] ([fdo#111045] / [fdo#111096]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505 [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045 [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [fdo#111800]: https://bugs.freedesktop.org/show_bug.cgi?id=111800 [fdo#112052 ]: https://bugs.freedesktop.org/show_bug.cgi?id=112052 [fdo#112120]: https://bugs.freedesktop.org/show_bug.cgi?id=112120 [fdo#112176]: https://bugs.freedesktop.org/show_bug.cgi?id=112176 Participating hosts (52 -> 44) ------------------------------ Missing (8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-ctg-p8600 fi-gdg-551 fi-byt-clapper Build changes ------------- * CI: CI-20190529 -> None * IGT: IGT_5261 -> IGTPW_3648 CI-20190529: 20190529 CI_DRM_7258: 51b92cc0826a46a2b6de4abee3edecb216bf0419 @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_3648: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/index.html IGT_5261: 6c3bae1455c373c49fe744ea037e33b11e8daf1e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/index.html _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev ^ permalink raw reply [flat|nested] 17+ messages in thread
* [igt-dev] ✓ Fi.CI.IGT: success for i915/gem_exec_balancer: Wait for both engines to complete before resubmitting 2019-11-04 20:17 ` Chris Wilson ` (2 preceding siblings ...) (?) @ 2019-11-05 7:36 ` Patchwork -1 siblings, 0 replies; 17+ messages in thread From: Patchwork @ 2019-11-05 7:36 UTC (permalink / raw) To: Chris Wilson; +Cc: igt-dev == Series Details == Series: i915/gem_exec_balancer: Wait for both engines to complete before resubmitting URL : https://patchwork.freedesktop.org/series/68966/ State : success == Summary == CI Bug Log - changes from CI_DRM_7258_full -> IGTPW_3648_full ==================================================== Summary ------- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/index.html Known issues ------------ Here are the changes found in IGTPW_3648_full that come from known issues: ### IGT changes ### #### Issues hit #### * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +11 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb2/igt@gem_busy@busy-vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-iclb8/igt@gem_busy@busy-vcs1.html * igt@gem_ctx_isolation@bcs0-s3: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl3/igt@gem_ctx_isolation@bcs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-kbl7/igt@gem_ctx_isolation@bcs0-s3.html * igt@gem_ctx_isolation@vcs1-dirty-create: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [fdo#112080]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb4/igt@gem_ctx_isolation@vcs1-dirty-create.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-iclb7/igt@gem_ctx_isolation@vcs1-dirty-create.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110854]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb2/igt@gem_exec_balancer@smoke.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-iclb3/igt@gem_exec_balancer@smoke.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +13 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb4/igt@gem_exec_schedule@independent-bsd2.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-iclb6/igt@gem_exec_schedule@independent-bsd2.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb5/igt@gem_exec_schedule@reorder-wide-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-iclb1/igt@gem_exec_schedule@reorder-wide-bsd.html * igt@gem_userptr_blits@map-fixed-invalidate-busy: - shard-snb: [PASS][13] -> [DMESG-WARN][14] ([fdo#111870]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-snb5/igt@gem_userptr_blits@map-fixed-invalidate-busy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-snb4/igt@gem_userptr_blits@map-fixed-invalidate-busy.html * igt@gem_userptr_blits@sync-unmap-cycles: - shard-hsw: [PASS][15] -> [DMESG-WARN][16] ([fdo#111870]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-hsw5/igt@gem_userptr_blits@sync-unmap-cycles.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-hsw1/igt@gem_userptr_blits@sync-unmap-cycles.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: [PASS][17] -> [SKIP][18] ([fdo#109271]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-snb7/igt@i915_pm_rc6_residency@rc6-accuracy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-snb7/igt@i915_pm_rc6_residency@rc6-accuracy.html * igt@i915_pm_rpm@system-suspend: - shard-kbl: [PASS][19] -> [INCOMPLETE][20] ([fdo#103665] / [fdo#107807]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl1/igt@i915_pm_rpm@system-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-kbl3/igt@i915_pm_rpm@system-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-256x85-sliding: - shard-kbl: [PASS][21] -> [FAIL][22] ([fdo#103232]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl2/igt@kms_cursor_crc@pipe-c-cursor-256x85-sliding.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-kbl4/igt@kms_cursor_crc@pipe-c-cursor-256x85-sliding.html - shard-apl: [PASS][23] -> [FAIL][24] ([fdo#103232]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-apl8/igt@kms_cursor_crc@pipe-c-cursor-256x85-sliding.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-apl2/igt@kms_cursor_crc@pipe-c-cursor-256x85-sliding.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][25] -> [INCOMPLETE][26] ([fdo#103665]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl6/igt@kms_cursor_crc@pipe-c-cursor-suspend.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-kbl3/igt@kms_cursor_crc@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][27] -> [FAIL][28] ([fdo#105767]) [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-hsw5/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-hsw6/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt: - shard-iclb: [PASS][29] -> [FAIL][30] ([fdo#103167]) +3 similar issues [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb1/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-iclb5/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt.html * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-blt: - shard-glk: [PASS][31] -> [FAIL][32] ([fdo#103167]) [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-glk3/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-blt.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-glk7/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-blt.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-apl: [PASS][33] -> [DMESG-WARN][34] ([fdo#108566]) +1 similar issue [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-apl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-apl7/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][35] -> [FAIL][36] ([fdo#103166]) [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb7/igt@kms_plane_lowres@pipe-a-tiling-y.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-iclb4/igt@kms_plane_lowres@pipe-a-tiling-y.html * igt@kms_setmode@basic: - shard-apl: [PASS][37] -> [FAIL][38] ([fdo#99912]) [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-apl1/igt@kms_setmode@basic.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-apl2/igt@kms_setmode@basic.html #### Possible fixes #### * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [DMESG-WARN][39] ([fdo#108566]) -> [PASS][40] +6 similar issues [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl7/igt@gem_ctx_isolation@rcs0-s3.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-kbl7/igt@gem_ctx_isolation@rcs0-s3.html * igt@gem_ctx_isolation@vcs1-clean: - shard-iclb: [SKIP][41] ([fdo#109276] / [fdo#112080]) -> [PASS][42] +2 similar issues [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb3/igt@gem_ctx_isolation@vcs1-clean.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-iclb1/igt@gem_ctx_isolation@vcs1-clean.html * igt@gem_ctx_isolation@vecs0-s3: - {shard-tglb}: [INCOMPLETE][43] ([fdo#111832]) -> [PASS][44] [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-tglb7/igt@gem_ctx_isolation@vecs0-s3.html [44]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-tglb5/igt@gem_ctx_isolation@vecs0-s3.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [SKIP][45] ([fdo#112080]) -> [PASS][46] +10 similar issues [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb6/igt@gem_exec_parallel@vcs1-fds.html [46]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-iclb1/igt@gem_exec_parallel@vcs1-fds.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [SKIP][47] ([fdo#112146]) -> [PASS][48] +6 similar issues [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb4/igt@gem_exec_schedule@preemptive-hang-bsd.html [48]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-iclb5/igt@gem_exec_schedule@preemptive-hang-bsd.html * igt@gem_userptr_blits@sync-unmap-after-close: - shard-hsw: [DMESG-WARN][49] ([fdo#111870]) -> [PASS][50] +4 similar issues [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-hsw6/igt@gem_userptr_blits@sync-unmap-after-close.html [50]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-hsw8/igt@gem_userptr_blits@sync-unmap-after-close.html * igt@gem_userptr_blits@sync-unmap-cycles: - shard-snb: [DMESG-WARN][51] ([fdo#111870]) -> [PASS][52] +3 similar issues [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-snb6/igt@gem_userptr_blits@sync-unmap-cycles.html [52]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-snb4/igt@gem_userptr_blits@sync-unmap-cycles.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-kbl: [SKIP][53] ([fdo#109271]) -> [PASS][54] [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl1/igt@i915_pm_rc6_residency@rc6-accuracy.html [54]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-kbl3/igt@i915_pm_rc6_residency@rc6-accuracy.html * igt@kms_cursor_edge_walk@pipe-b-256x256-left-edge: - shard-snb: [SKIP][55] ([fdo#109271]) -> [PASS][56] [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-snb4/igt@kms_cursor_edge_walk@pipe-b-256x256-left-edge.html [56]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-snb5/igt@kms_cursor_edge_walk@pipe-b-256x256-left-edge.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: [FAIL][57] ([fdo#105363]) -> [PASS][58] [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-glk6/igt@kms_flip@flip-vs-expired-vblank-interruptible.html [58]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-glk6/igt@kms_flip@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend: - shard-apl: [DMESG-WARN][59] ([fdo#108566]) -> [PASS][60] [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-apl1/igt@kms_flip@flip-vs-suspend.html [60]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-apl8/igt@kms_flip@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-blt: - shard-iclb: [FAIL][61] ([fdo#103167]) -> [PASS][62] +5 similar issues [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb2/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-blt.html [62]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-iclb5/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-blt.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite: - {shard-tglb}: [FAIL][63] ([fdo#103167]) -> [PASS][64] +2 similar issues [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-tglb2/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html [64]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-tglb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [FAIL][65] ([fdo#103166]) -> [PASS][66] [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb8/igt@kms_plane_lowres@pipe-a-tiling-x.html [66]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-iclb1/igt@kms_plane_lowres@pipe-a-tiling-x.html * igt@kms_psr@no_drrs: - shard-iclb: [FAIL][67] ([fdo#108341]) -> [PASS][68] [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb1/igt@kms_psr@no_drrs.html [68]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-iclb5/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_basic: - shard-iclb: [SKIP][69] ([fdo#109441]) -> [PASS][70] [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb5/igt@kms_psr@psr2_basic.html [70]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-iclb2/igt@kms_psr@psr2_basic.html * igt@kms_psr@suspend: - {shard-tglb}: [INCOMPLETE][71] ([fdo#111832] / [fdo#111850]) -> [PASS][72] +1 similar issue [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-tglb8/igt@kms_psr@suspend.html [72]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-tglb3/igt@kms_psr@suspend.html * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend: - {shard-tglb}: [INCOMPLETE][73] ([fdo#111850]) -> [PASS][74] [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-tglb7/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html [74]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-tglb4/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html * igt@prime_busy@hang-bsd2: - shard-iclb: [SKIP][75] ([fdo#109276]) -> [PASS][76] +24 similar issues [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb7/igt@prime_busy@hang-bsd2.html [76]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-iclb2/igt@prime_busy@hang-bsd2.html #### Warnings #### * igt@gem_mocs_settings@mocs-rc6-bsd2: - shard-iclb: [FAIL][77] ([fdo#111330]) -> [SKIP][78] ([fdo#109276]) [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb4/igt@gem_mocs_settings@mocs-rc6-bsd2.html [78]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-iclb8/igt@gem_mocs_settings@mocs-rc6-bsd2.html * igt@i915_suspend@fence-restore-untiled: - shard-kbl: [INCOMPLETE][79] ([fdo#103665]) -> [DMESG-WARN][80] ([fdo#108566]) [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl4/igt@i915_suspend@fence-restore-untiled.html [80]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/shard-kbl6/igt@i915_suspend@fence-restore-untiled.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232 [fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665 [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363 [fdo#105767]: https://bugs.freedesktop.org/show_bug.cgi?id=105767 [fdo#107383]: https://bugs.freedesktop.org/show_bug.cgi?id=107383 [fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807 [fdo#108341]: https://bugs.freedesktop.org/show_bug.cgi?id=108341 [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566 [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 [fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854 [fdo#111329]: https://bugs.freedesktop.org/show_bug.cgi?id=111329 [fdo#111330]: https://bugs.freedesktop.org/show_bug.cgi?id=111330 [fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600 [fdo#111646]: https://bugs.freedesktop.org/show_bug.cgi?id=111646 [fdo#111647]: https://bugs.freedesktop.org/show_bug.cgi?id=111647 [fdo#111671]: https://bugs.freedesktop.org/show_bug.cgi?id=111671 [fdo#111703]: https://bugs.freedesktop.org/show_bug.cgi?id=111703 [fdo#111832]: https://bugs.freedesktop.org/show_bug.cgi?id=111832 [fdo#111850]: https://bugs.freedesktop.org/show_bug.cgi?id=111850 [fdo#111870]: https://bugs.freedesktop.org/show_bug.cgi?id=111870 [fdo#111998]: https://bugs.freedesktop.org/show_bug.cgi?id=111998 [fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080 [fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146 [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912 Participating hosts (11 -> 8) ------------------------------ Missing (3): pig-skl-6260u pig-glk-j5005 pig-hsw-4770r Build changes ------------- * CI: CI-20190529 -> None * IGT: IGT_5261 -> IGTPW_3648 * Piglit: piglit_4509 -> None CI-20190529: 20190529 CI_DRM_7258: 51b92cc0826a46a2b6de4abee3edecb216bf0419 @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_3648: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/index.html IGT_5261: 6c3bae1455c373c49fe744ea037e33b11e8daf1e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3648/index.html _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [igt-dev] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting 2019-11-04 20:17 ` Chris Wilson (?) @ 2019-11-05 11:34 ` Mika Kuoppala -1 siblings, 0 replies; 17+ messages in thread From: Mika Kuoppala @ 2019-11-05 11:34 UTC (permalink / raw) To: Chris Wilson, intel-gfx; +Cc: igt-dev, Tvrtko Ursulin Chris Wilson <chris@chris-wilson.co.uk> writes: > As the scratch buf is shared between the two requests on both engines, > we need to wait for both to finish using the buffer before we reset it. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > --- > tests/i915/gem_exec_balancer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c > index e52f5df95..70c4529b4 100644 > --- a/tests/i915/gem_exec_balancer.c > +++ b/tests/i915/gem_exec_balancer.c > @@ -840,7 +840,7 @@ static void bonded_slice(int i915) > gem_execbuf(i915, &eb); > close(eb.rsvd2); > > - gem_sync(i915, obj[2].handle); > + gem_sync(i915, obj[0].handle); Ok, let me try to make sense of it all. First off, the need for obj[IGT_SPIN_SCRATCH].handle grows. But as the semaphore will wait the spinner to start and then end it. It is not enough to wait the semaphore batch to sync. That is clear. But on syncing the scratch: the obj[1].handle is causing write hazard to obj[0] so if we wait obj[0], then it is implied that obj[1].handle has finished? -Mika > } > > *stop = 1; > -- > 2.24.0 _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting @ 2019-11-05 11:34 ` Mika Kuoppala 0 siblings, 0 replies; 17+ messages in thread From: Mika Kuoppala @ 2019-11-05 11:34 UTC (permalink / raw) To: Chris Wilson, intel-gfx; +Cc: igt-dev Chris Wilson <chris@chris-wilson.co.uk> writes: > As the scratch buf is shared between the two requests on both engines, > we need to wait for both to finish using the buffer before we reset it. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > --- > tests/i915/gem_exec_balancer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c > index e52f5df95..70c4529b4 100644 > --- a/tests/i915/gem_exec_balancer.c > +++ b/tests/i915/gem_exec_balancer.c > @@ -840,7 +840,7 @@ static void bonded_slice(int i915) > gem_execbuf(i915, &eb); > close(eb.rsvd2); > > - gem_sync(i915, obj[2].handle); > + gem_sync(i915, obj[0].handle); Ok, let me try to make sense of it all. First off, the need for obj[IGT_SPIN_SCRATCH].handle grows. But as the semaphore will wait the spinner to start and then end it. It is not enough to wait the semaphore batch to sync. That is clear. But on syncing the scratch: the obj[1].handle is causing write hazard to obj[0] so if we wait obj[0], then it is implied that obj[1].handle has finished? -Mika > } > > *stop = 1; > -- > 2.24.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting @ 2019-11-05 11:34 ` Mika Kuoppala 0 siblings, 0 replies; 17+ messages in thread From: Mika Kuoppala @ 2019-11-05 11:34 UTC (permalink / raw) To: Chris Wilson, intel-gfx; +Cc: igt-dev Chris Wilson <chris@chris-wilson.co.uk> writes: > As the scratch buf is shared between the two requests on both engines, > we need to wait for both to finish using the buffer before we reset it. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > --- > tests/i915/gem_exec_balancer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c > index e52f5df95..70c4529b4 100644 > --- a/tests/i915/gem_exec_balancer.c > +++ b/tests/i915/gem_exec_balancer.c > @@ -840,7 +840,7 @@ static void bonded_slice(int i915) > gem_execbuf(i915, &eb); > close(eb.rsvd2); > > - gem_sync(i915, obj[2].handle); > + gem_sync(i915, obj[0].handle); Ok, let me try to make sense of it all. First off, the need for obj[IGT_SPIN_SCRATCH].handle grows. But as the semaphore will wait the spinner to start and then end it. It is not enough to wait the semaphore batch to sync. That is clear. But on syncing the scratch: the obj[1].handle is causing write hazard to obj[0] so if we wait obj[0], then it is implied that obj[1].handle has finished? -Mika > } > > *stop = 1; > -- > 2.24.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [igt-dev] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting 2019-11-05 11:34 ` Mika Kuoppala (?) @ 2019-11-05 11:39 ` Chris Wilson -1 siblings, 0 replies; 17+ messages in thread From: Chris Wilson @ 2019-11-05 11:39 UTC (permalink / raw) To: Mika Kuoppala, intel-gfx; +Cc: igt-dev, Tvrtko Ursulin Quoting Mika Kuoppala (2019-11-05 11:34:23) > Chris Wilson <chris@chris-wilson.co.uk> writes: > > > As the scratch buf is shared between the two requests on both engines, > > we need to wait for both to finish using the buffer before we reset it. > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > > --- > > tests/i915/gem_exec_balancer.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c > > index e52f5df95..70c4529b4 100644 > > --- a/tests/i915/gem_exec_balancer.c > > +++ b/tests/i915/gem_exec_balancer.c > > @@ -840,7 +840,7 @@ static void bonded_slice(int i915) > > gem_execbuf(i915, &eb); > > close(eb.rsvd2); > > > > - gem_sync(i915, obj[2].handle); > > + gem_sync(i915, obj[0].handle); > > Ok, let me try to make sense of it all. First off, the need for > obj[IGT_SPIN_SCRATCH].handle grows. > > But as the semaphore will wait the spinner to start and then end it. > It is not enough to wait the semaphore batch to sync. That is clear. It should be enough to wait for the spinner completion to be sure that the semaphore batch is past the point of no return (but not necessarily complete as it may be preempted before we mark it as complete). So it would be possible for us to see the context still in flight and reduce the randomness of our selection. > But on syncing the scratch: the obj[1].handle is causing write > hazard to obj[0] so if we wait obj[0], then it is implied that > obj[1].handle has finished? Yes. obj[2].handle has one fence (from the spinner batch), obj[0].handle has two fences (from both batches), likewise obj[1].handle. So if you wait on either obj[0].handle or obj[1].handle, you flush both fences. -Chris _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting @ 2019-11-05 11:39 ` Chris Wilson 0 siblings, 0 replies; 17+ messages in thread From: Chris Wilson @ 2019-11-05 11:39 UTC (permalink / raw) To: Mika Kuoppala, intel-gfx; +Cc: igt-dev Quoting Mika Kuoppala (2019-11-05 11:34:23) > Chris Wilson <chris@chris-wilson.co.uk> writes: > > > As the scratch buf is shared between the two requests on both engines, > > we need to wait for both to finish using the buffer before we reset it. > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > > --- > > tests/i915/gem_exec_balancer.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c > > index e52f5df95..70c4529b4 100644 > > --- a/tests/i915/gem_exec_balancer.c > > +++ b/tests/i915/gem_exec_balancer.c > > @@ -840,7 +840,7 @@ static void bonded_slice(int i915) > > gem_execbuf(i915, &eb); > > close(eb.rsvd2); > > > > - gem_sync(i915, obj[2].handle); > > + gem_sync(i915, obj[0].handle); > > Ok, let me try to make sense of it all. First off, the need for > obj[IGT_SPIN_SCRATCH].handle grows. > > But as the semaphore will wait the spinner to start and then end it. > It is not enough to wait the semaphore batch to sync. That is clear. It should be enough to wait for the spinner completion to be sure that the semaphore batch is past the point of no return (but not necessarily complete as it may be preempted before we mark it as complete). So it would be possible for us to see the context still in flight and reduce the randomness of our selection. > But on syncing the scratch: the obj[1].handle is causing write > hazard to obj[0] so if we wait obj[0], then it is implied that > obj[1].handle has finished? Yes. obj[2].handle has one fence (from the spinner batch), obj[0].handle has two fences (from both batches), likewise obj[1].handle. So if you wait on either obj[0].handle or obj[1].handle, you flush both fences. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting @ 2019-11-05 11:39 ` Chris Wilson 0 siblings, 0 replies; 17+ messages in thread From: Chris Wilson @ 2019-11-05 11:39 UTC (permalink / raw) To: Mika Kuoppala, intel-gfx; +Cc: igt-dev Quoting Mika Kuoppala (2019-11-05 11:34:23) > Chris Wilson <chris@chris-wilson.co.uk> writes: > > > As the scratch buf is shared between the two requests on both engines, > > we need to wait for both to finish using the buffer before we reset it. > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > > --- > > tests/i915/gem_exec_balancer.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c > > index e52f5df95..70c4529b4 100644 > > --- a/tests/i915/gem_exec_balancer.c > > +++ b/tests/i915/gem_exec_balancer.c > > @@ -840,7 +840,7 @@ static void bonded_slice(int i915) > > gem_execbuf(i915, &eb); > > close(eb.rsvd2); > > > > - gem_sync(i915, obj[2].handle); > > + gem_sync(i915, obj[0].handle); > > Ok, let me try to make sense of it all. First off, the need for > obj[IGT_SPIN_SCRATCH].handle grows. > > But as the semaphore will wait the spinner to start and then end it. > It is not enough to wait the semaphore batch to sync. That is clear. It should be enough to wait for the spinner completion to be sure that the semaphore batch is past the point of no return (but not necessarily complete as it may be preempted before we mark it as complete). So it would be possible for us to see the context still in flight and reduce the randomness of our selection. > But on syncing the scratch: the obj[1].handle is causing write > hazard to obj[0] so if we wait obj[0], then it is implied that > obj[1].handle has finished? Yes. obj[2].handle has one fence (from the spinner batch), obj[0].handle has two fences (from both batches), likewise obj[1].handle. So if you wait on either obj[0].handle or obj[1].handle, you flush both fences. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [igt-dev] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting 2019-11-05 11:39 ` Chris Wilson (?) @ 2019-11-05 11:46 ` Mika Kuoppala -1 siblings, 0 replies; 17+ messages in thread From: Mika Kuoppala @ 2019-11-05 11:46 UTC (permalink / raw) To: Chris Wilson, intel-gfx; +Cc: igt-dev, Tvrtko Ursulin Chris Wilson <chris@chris-wilson.co.uk> writes: > Quoting Mika Kuoppala (2019-11-05 11:34:23) >> Chris Wilson <chris@chris-wilson.co.uk> writes: >> >> > As the scratch buf is shared between the two requests on both engines, >> > we need to wait for both to finish using the buffer before we reset it. >> > >> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> >> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> >> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> >> > --- >> > tests/i915/gem_exec_balancer.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c >> > index e52f5df95..70c4529b4 100644 >> > --- a/tests/i915/gem_exec_balancer.c >> > +++ b/tests/i915/gem_exec_balancer.c >> > @@ -840,7 +840,7 @@ static void bonded_slice(int i915) >> > gem_execbuf(i915, &eb); >> > close(eb.rsvd2); >> > >> > - gem_sync(i915, obj[2].handle); >> > + gem_sync(i915, obj[0].handle); >> >> Ok, let me try to make sense of it all. First off, the need for >> obj[IGT_SPIN_SCRATCH].handle grows. >> >> But as the semaphore will wait the spinner to start and then end it. >> It is not enough to wait the semaphore batch to sync. That is clear. > > It should be enough to wait for the spinner completion to be sure that > the semaphore batch is past the point of no return (but not necessarily > complete as it may be preempted before we mark it as complete). So it > would be possible for us to see the context still in flight and reduce > the randomness of our selection. > >> But on syncing the scratch: the obj[1].handle is causing write >> hazard to obj[0] so if we wait obj[0], then it is implied that >> obj[1].handle has finished? > > Yes. obj[2].handle has one fence (from the spinner batch), obj[0].handle > has two fences (from both batches), likewise obj[1].handle. So if you > wait on either obj[0].handle or obj[1].handle, you flush both fences. We need to get rid of the absolute indexing inside spin handles at some point. But not today. Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> > -Chris _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting @ 2019-11-05 11:46 ` Mika Kuoppala 0 siblings, 0 replies; 17+ messages in thread From: Mika Kuoppala @ 2019-11-05 11:46 UTC (permalink / raw) To: Chris Wilson, intel-gfx; +Cc: igt-dev Chris Wilson <chris@chris-wilson.co.uk> writes: > Quoting Mika Kuoppala (2019-11-05 11:34:23) >> Chris Wilson <chris@chris-wilson.co.uk> writes: >> >> > As the scratch buf is shared between the two requests on both engines, >> > we need to wait for both to finish using the buffer before we reset it. >> > >> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> >> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> >> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> >> > --- >> > tests/i915/gem_exec_balancer.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c >> > index e52f5df95..70c4529b4 100644 >> > --- a/tests/i915/gem_exec_balancer.c >> > +++ b/tests/i915/gem_exec_balancer.c >> > @@ -840,7 +840,7 @@ static void bonded_slice(int i915) >> > gem_execbuf(i915, &eb); >> > close(eb.rsvd2); >> > >> > - gem_sync(i915, obj[2].handle); >> > + gem_sync(i915, obj[0].handle); >> >> Ok, let me try to make sense of it all. First off, the need for >> obj[IGT_SPIN_SCRATCH].handle grows. >> >> But as the semaphore will wait the spinner to start and then end it. >> It is not enough to wait the semaphore batch to sync. That is clear. > > It should be enough to wait for the spinner completion to be sure that > the semaphore batch is past the point of no return (but not necessarily > complete as it may be preempted before we mark it as complete). So it > would be possible for us to see the context still in flight and reduce > the randomness of our selection. > >> But on syncing the scratch: the obj[1].handle is causing write >> hazard to obj[0] so if we wait obj[0], then it is implied that >> obj[1].handle has finished? > > Yes. obj[2].handle has one fence (from the spinner batch), obj[0].handle > has two fences (from both batches), likewise obj[1].handle. So if you > wait on either obj[0].handle or obj[1].handle, you flush both fences. We need to get rid of the absolute indexing inside spin handles at some point. But not today. Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting @ 2019-11-05 11:46 ` Mika Kuoppala 0 siblings, 0 replies; 17+ messages in thread From: Mika Kuoppala @ 2019-11-05 11:46 UTC (permalink / raw) To: Chris Wilson, intel-gfx; +Cc: igt-dev Chris Wilson <chris@chris-wilson.co.uk> writes: > Quoting Mika Kuoppala (2019-11-05 11:34:23) >> Chris Wilson <chris@chris-wilson.co.uk> writes: >> >> > As the scratch buf is shared between the two requests on both engines, >> > we need to wait for both to finish using the buffer before we reset it. >> > >> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> >> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> >> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> >> > --- >> > tests/i915/gem_exec_balancer.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c >> > index e52f5df95..70c4529b4 100644 >> > --- a/tests/i915/gem_exec_balancer.c >> > +++ b/tests/i915/gem_exec_balancer.c >> > @@ -840,7 +840,7 @@ static void bonded_slice(int i915) >> > gem_execbuf(i915, &eb); >> > close(eb.rsvd2); >> > >> > - gem_sync(i915, obj[2].handle); >> > + gem_sync(i915, obj[0].handle); >> >> Ok, let me try to make sense of it all. First off, the need for >> obj[IGT_SPIN_SCRATCH].handle grows. >> >> But as the semaphore will wait the spinner to start and then end it. >> It is not enough to wait the semaphore batch to sync. That is clear. > > It should be enough to wait for the spinner completion to be sure that > the semaphore batch is past the point of no return (but not necessarily > complete as it may be preempted before we mark it as complete). So it > would be possible for us to see the context still in flight and reduce > the randomness of our selection. > >> But on syncing the scratch: the obj[1].handle is causing write >> hazard to obj[0] so if we wait obj[0], then it is implied that >> obj[1].handle has finished? > > Yes. obj[2].handle has one fence (from the spinner batch), obj[0].handle > has two fences (from both batches), likewise obj[1].handle. So if you > wait on either obj[0].handle or obj[1].handle, you flush both fences. We need to get rid of the absolute indexing inside spin handles at some point. But not today. Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [igt-dev] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting 2019-11-05 11:46 ` Mika Kuoppala (?) @ 2019-11-05 11:48 ` Chris Wilson -1 siblings, 0 replies; 17+ messages in thread From: Chris Wilson @ 2019-11-05 11:48 UTC (permalink / raw) To: Mika Kuoppala, intel-gfx; +Cc: igt-dev, Tvrtko Ursulin Quoting Mika Kuoppala (2019-11-05 11:46:53) > Chris Wilson <chris@chris-wilson.co.uk> writes: > > > Quoting Mika Kuoppala (2019-11-05 11:34:23) > >> Chris Wilson <chris@chris-wilson.co.uk> writes: > >> > >> > As the scratch buf is shared between the two requests on both engines, > >> > we need to wait for both to finish using the buffer before we reset it. > >> > > >> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > >> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> > >> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > >> > --- > >> > tests/i915/gem_exec_balancer.c | 2 +- > >> > 1 file changed, 1 insertion(+), 1 deletion(-) > >> > > >> > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c > >> > index e52f5df95..70c4529b4 100644 > >> > --- a/tests/i915/gem_exec_balancer.c > >> > +++ b/tests/i915/gem_exec_balancer.c > >> > @@ -840,7 +840,7 @@ static void bonded_slice(int i915) > >> > gem_execbuf(i915, &eb); > >> > close(eb.rsvd2); > >> > > >> > - gem_sync(i915, obj[2].handle); > >> > + gem_sync(i915, obj[0].handle); > >> > >> Ok, let me try to make sense of it all. First off, the need for > >> obj[IGT_SPIN_SCRATCH].handle grows. > >> > >> But as the semaphore will wait the spinner to start and then end it. > >> It is not enough to wait the semaphore batch to sync. That is clear. > > > > It should be enough to wait for the spinner completion to be sure that > > the semaphore batch is past the point of no return (but not necessarily > > complete as it may be preempted before we mark it as complete). So it > > would be possible for us to see the context still in flight and reduce > > the randomness of our selection. > > > >> But on syncing the scratch: the obj[1].handle is causing write > >> hazard to obj[0] so if we wait obj[0], then it is implied that > >> obj[1].handle has finished? > > > > Yes. obj[2].handle has one fence (from the spinner batch), obj[0].handle > > has two fences (from both batches), likewise obj[1].handle. So if you > > wait on either obj[0].handle or obj[1].handle, you flush both fences. > > We need to get rid of the absolute indexing inside spin handles > at some point. But not today. Yeah, right :-p -Chris _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting @ 2019-11-05 11:48 ` Chris Wilson 0 siblings, 0 replies; 17+ messages in thread From: Chris Wilson @ 2019-11-05 11:48 UTC (permalink / raw) To: Mika Kuoppala, intel-gfx; +Cc: igt-dev Quoting Mika Kuoppala (2019-11-05 11:46:53) > Chris Wilson <chris@chris-wilson.co.uk> writes: > > > Quoting Mika Kuoppala (2019-11-05 11:34:23) > >> Chris Wilson <chris@chris-wilson.co.uk> writes: > >> > >> > As the scratch buf is shared between the two requests on both engines, > >> > we need to wait for both to finish using the buffer before we reset it. > >> > > >> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > >> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> > >> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > >> > --- > >> > tests/i915/gem_exec_balancer.c | 2 +- > >> > 1 file changed, 1 insertion(+), 1 deletion(-) > >> > > >> > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c > >> > index e52f5df95..70c4529b4 100644 > >> > --- a/tests/i915/gem_exec_balancer.c > >> > +++ b/tests/i915/gem_exec_balancer.c > >> > @@ -840,7 +840,7 @@ static void bonded_slice(int i915) > >> > gem_execbuf(i915, &eb); > >> > close(eb.rsvd2); > >> > > >> > - gem_sync(i915, obj[2].handle); > >> > + gem_sync(i915, obj[0].handle); > >> > >> Ok, let me try to make sense of it all. First off, the need for > >> obj[IGT_SPIN_SCRATCH].handle grows. > >> > >> But as the semaphore will wait the spinner to start and then end it. > >> It is not enough to wait the semaphore batch to sync. That is clear. > > > > It should be enough to wait for the spinner completion to be sure that > > the semaphore batch is past the point of no return (but not necessarily > > complete as it may be preempted before we mark it as complete). So it > > would be possible for us to see the context still in flight and reduce > > the randomness of our selection. > > > >> But on syncing the scratch: the obj[1].handle is causing write > >> hazard to obj[0] so if we wait obj[0], then it is implied that > >> obj[1].handle has finished? > > > > Yes. obj[2].handle has one fence (from the spinner batch), obj[0].handle > > has two fences (from both batches), likewise obj[1].handle. So if you > > wait on either obj[0].handle or obj[1].handle, you flush both fences. > > We need to get rid of the absolute indexing inside spin handles > at some point. But not today. Yeah, right :-p -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting @ 2019-11-05 11:48 ` Chris Wilson 0 siblings, 0 replies; 17+ messages in thread From: Chris Wilson @ 2019-11-05 11:48 UTC (permalink / raw) To: Mika Kuoppala, intel-gfx; +Cc: igt-dev Quoting Mika Kuoppala (2019-11-05 11:46:53) > Chris Wilson <chris@chris-wilson.co.uk> writes: > > > Quoting Mika Kuoppala (2019-11-05 11:34:23) > >> Chris Wilson <chris@chris-wilson.co.uk> writes: > >> > >> > As the scratch buf is shared between the two requests on both engines, > >> > we need to wait for both to finish using the buffer before we reset it. > >> > > >> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > >> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> > >> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > >> > --- > >> > tests/i915/gem_exec_balancer.c | 2 +- > >> > 1 file changed, 1 insertion(+), 1 deletion(-) > >> > > >> > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c > >> > index e52f5df95..70c4529b4 100644 > >> > --- a/tests/i915/gem_exec_balancer.c > >> > +++ b/tests/i915/gem_exec_balancer.c > >> > @@ -840,7 +840,7 @@ static void bonded_slice(int i915) > >> > gem_execbuf(i915, &eb); > >> > close(eb.rsvd2); > >> > > >> > - gem_sync(i915, obj[2].handle); > >> > + gem_sync(i915, obj[0].handle); > >> > >> Ok, let me try to make sense of it all. First off, the need for > >> obj[IGT_SPIN_SCRATCH].handle grows. > >> > >> But as the semaphore will wait the spinner to start and then end it. > >> It is not enough to wait the semaphore batch to sync. That is clear. > > > > It should be enough to wait for the spinner completion to be sure that > > the semaphore batch is past the point of no return (but not necessarily > > complete as it may be preempted before we mark it as complete). So it > > would be possible for us to see the context still in flight and reduce > > the randomness of our selection. > > > >> But on syncing the scratch: the obj[1].handle is causing write > >> hazard to obj[0] so if we wait obj[0], then it is implied that > >> obj[1].handle has finished? > > > > Yes. obj[2].handle has one fence (from the spinner batch), obj[0].handle > > has two fences (from both batches), likewise obj[1].handle. So if you > > wait on either obj[0].handle or obj[1].handle, you flush both fences. > > We need to get rid of the absolute indexing inside spin handles > at some point. But not today. Yeah, right :-p -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2019-11-05 11:48 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-11-04 20:17 [igt-dev] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting Chris Wilson 2019-11-04 20:17 ` [Intel-gfx] " Chris Wilson 2019-11-04 20:17 ` Chris Wilson 2019-11-04 20:57 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork 2019-11-05 7:36 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork 2019-11-05 11:34 ` [igt-dev] [PATCH i-g-t] " Mika Kuoppala 2019-11-05 11:34 ` [Intel-gfx] " Mika Kuoppala 2019-11-05 11:34 ` Mika Kuoppala 2019-11-05 11:39 ` [igt-dev] " Chris Wilson 2019-11-05 11:39 ` [Intel-gfx] " Chris Wilson 2019-11-05 11:39 ` Chris Wilson 2019-11-05 11:46 ` [igt-dev] " Mika Kuoppala 2019-11-05 11:46 ` [Intel-gfx] " Mika Kuoppala 2019-11-05 11:46 ` Mika Kuoppala 2019-11-05 11:48 ` [igt-dev] " Chris Wilson 2019-11-05 11:48 ` [Intel-gfx] " Chris Wilson 2019-11-05 11:48 ` Chris Wilson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.