| Message ID | 20190614213749.15870-1-jose.souza@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/i915/ehl: Add missing VECS engine | expand |
On Fri, Jun 14, 2019 at 02:37:49PM -0700, José Roberto de Souza wrote: > EHL can have up to one VECS(video enhancement) engine, so add it to > the device_info. Bspec 29150 has a footnote on VEbox that indicates "Pass-through only, no VEbox processing logic." That note seems a bit vague, but I think I saw some more detailed info in the past somewhere that indicated the VECS command streamer is still technically present but doesn't actually do any video enhancement on EHL; it just passes content through to SFC. I'm not terribly plugged into the media side of the world, so I'm not sure if we want to expose VECS to userspace if it's basically a noop and doesn't do what it normally does on other platforms. Bspec page 5229 implies that SFC can be fed directly by the decode engine without going through VEBOX, so I'm not sure if media userspace would ever have a use for the passthrough-only VECS streamer. We should probably ask someone on the media team what their thoughts are on this. Matt > > BSpec: 29152 > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > Cc: Bob Paauwe <bob.j.paauwe@intel.com> > Cc: Matt Roper <matthew.d.roper@intel.com> > Cc: Clint Taylor <Clinton.A.Taylor@intel.com> > Signed-off-by: José Roberto de Souza <jose.souza@intel.com> > --- > drivers/gpu/drm/i915/i915_pci.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c > index 482f1d0f1770..2c5f64ccadb5 100644 > --- a/drivers/gpu/drm/i915/i915_pci.c > +++ b/drivers/gpu/drm/i915/i915_pci.c > @@ -760,7 +760,7 @@ static const struct intel_device_info intel_elkhartlake_info = { > GEN11_FEATURES, > PLATFORM(INTEL_ELKHARTLAKE), > .require_force_probe = 1, > - .engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0), > + .engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0) | BIT(VECS0), > .ppgtt_size = 36, > }; > > -- > 2.22.0 >
On Fri, 2019-06-14 at 15:17 -0700, Matt Roper wrote: > On Fri, Jun 14, 2019 at 02:37:49PM -0700, José Roberto de Souza > wrote: > > EHL can have up to one VECS(video enhancement) engine, so add it to > > the device_info. > > Bspec 29150 has a footnote on VEbox that indicates "Pass-through > only, > no VEbox processing logic." That note seems a bit vague, but I think > I > saw some more detailed info in the past somewhere that indicated the > VECS command streamer is still technically present but doesn't > actually > do any video enhancement on EHL; it just passes content through to > SFC. > > I'm not terribly plugged into the media side of the world, so I'm not > sure if we want to expose VECS to userspace if it's basically a noop > and > doesn't do what it normally does on other platforms. Bspec page 5229 > implies that SFC can be fed directly by the decode engine without > going > through VEBOX, so I'm not sure if media userspace would ever have a > use > for the passthrough-only VECS streamer. > > We should probably ask someone on the media team what their thoughts > are > on this. I just sent a question to media team but in any case we are going need to some change around it otherwise driver would crash when CONFIG_DRM_I915_DEBUG_GEM is set: intel_device_info_init_mmio() GEM_BUG_ON(vebox_mask != VEBOX_MASK(dev_priv)); > > > Matt > > > BSpec: 29152 > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Cc: Bob Paauwe <bob.j.paauwe@intel.com> > > Cc: Matt Roper <matthew.d.roper@intel.com> > > Cc: Clint Taylor <Clinton.A.Taylor@intel.com> > > Signed-off-by: José Roberto de Souza <jose.souza@intel.com> > > --- > > drivers/gpu/drm/i915/i915_pci.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_pci.c > > b/drivers/gpu/drm/i915/i915_pci.c > > index 482f1d0f1770..2c5f64ccadb5 100644 > > --- a/drivers/gpu/drm/i915/i915_pci.c > > +++ b/drivers/gpu/drm/i915/i915_pci.c > > @@ -760,7 +760,7 @@ static const struct intel_device_info > > intel_elkhartlake_info = { > > GEN11_FEATURES, > > PLATFORM(INTEL_ELKHARTLAKE), > > .require_force_probe = 1, > > - .engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0), > > + .engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0) | BIT(VECS0), > > .ppgtt_size = 36, > > }; > > > > -- > > 2.22.0 > >
On Fri, Jun 14, 2019 at 03:17:39PM -0700, Matt Roper wrote: > On Fri, Jun 14, 2019 at 02:37:49PM -0700, José Roberto de Souza wrote: > > EHL can have up to one VECS(video enhancement) engine, so add it to > > the device_info. > > Bspec 29150 has a footnote on VEbox that indicates "Pass-through only, > no VEbox processing logic." That note seems a bit vague, but I think I > saw some more detailed info in the past somewhere that indicated the > VECS command streamer is still technically present but doesn't actually > do any video enhancement on EHL; it just passes content through to SFC. > > I'm not terribly plugged into the media side of the world, so I'm not > sure if we want to expose VECS to userspace if it's basically a noop and > doesn't do what it normally does on other platforms. Bspec page 5229 > implies that SFC can be fed directly by the decode engine without going > through VEBOX, so I'm not sure if media userspace would ever have a use > for the passthrough-only VECS streamer. > > We should probably ask someone on the media team what their thoughts are > on this. Since the media team confirmed that there is indeed a use case for a passthrough-only VECS, Reviewed-by: Matt Roper <matthew.d.roper@intel.com> > > > Matt > > > > > BSpec: 29152 > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Cc: Bob Paauwe <bob.j.paauwe@intel.com> > > Cc: Matt Roper <matthew.d.roper@intel.com> > > Cc: Clint Taylor <Clinton.A.Taylor@intel.com> > > Signed-off-by: José Roberto de Souza <jose.souza@intel.com> > > --- > > drivers/gpu/drm/i915/i915_pci.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c > > index 482f1d0f1770..2c5f64ccadb5 100644 > > --- a/drivers/gpu/drm/i915/i915_pci.c > > +++ b/drivers/gpu/drm/i915/i915_pci.c > > @@ -760,7 +760,7 @@ static const struct intel_device_info intel_elkhartlake_info = { > > GEN11_FEATURES, > > PLATFORM(INTEL_ELKHARTLAKE), > > .require_force_probe = 1, > > - .engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0), > > + .engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0) | BIT(VECS0), > > .ppgtt_size = 36, > > }; > > > > -- > > 2.22.0 > > > > -- > Matt Roper > Graphics Software Engineer > IoTG Platform Enabling & Development > Intel Corporation > (916) 356-2795 > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Matt Roper (2019-06-25 16:26:48) > On Fri, Jun 14, 2019 at 03:17:39PM -0700, Matt Roper wrote: > > On Fri, Jun 14, 2019 at 02:37:49PM -0700, José Roberto de Souza wrote: > > > EHL can have up to one VECS(video enhancement) engine, so add it to > > > the device_info. > > > > Bspec 29150 has a footnote on VEbox that indicates "Pass-through only, > > no VEbox processing logic." That note seems a bit vague, but I think I > > saw some more detailed info in the past somewhere that indicated the > > VECS command streamer is still technically present but doesn't actually > > do any video enhancement on EHL; it just passes content through to SFC. > > > > I'm not terribly plugged into the media side of the world, so I'm not > > sure if we want to expose VECS to userspace if it's basically a noop and > > doesn't do what it normally does on other platforms. Bspec page 5229 > > implies that SFC can be fed directly by the decode engine without going > > through VEBOX, so I'm not sure if media userspace would ever have a use > > for the passthrough-only VECS streamer. > > > > We should probably ask someone on the media team what their thoughts are > > on this. > > Since the media team confirmed that there is indeed a use case for a > passthrough-only VECS, If the CS exists as a separate entity sure... Any chance we can get an ehl into CI to actually confirm this? -Chris
On Mon, 2019-06-17 at 10:19 +0000, Patchwork wrote: > == Series Details == > > Series: drm/i915/ehl: Add missing VECS engine > URL : https://patchwork.freedesktop.org/series/62143/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_6277_full -> Patchwork_13297_full > ==================================================== > > Summary > ------- > > **SUCCESS** > > No regressions found. Thanks for the review Matt Pushed to dinq > > > > Known issues > ------------ > > Here are the changes found in Patchwork_13297_full that come from > known issues: > > ### IGT changes ### > > #### Issues hit #### > > * igt@gem_exec_balancer@smoke: > - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854]) > [1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb4/igt@gem_exec_balancer@smoke.html > [2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-iclb8/igt@gem_exec_balancer@smoke.html > > * igt@gem > _persistent_relocs@forked-interruptible-faulting-reloc-thrash-inactive > : > - shard-snb: [PASS][3] -> [INCOMPLETE][4] ([fdo#105411]) > [3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-snb5/igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrash-inactive.html > [4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-snb4/igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrash-inactive.html > > * igt@gem_persistent_relocs@forked-interruptible-thrashing: > - shard-snb: [PASS][5] -> [DMESG-WARN][6] ([fdo#110789] > / [fdo#110913 ]) > [5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-snb6/igt@gem_persistent_relocs@forked-interruptible-thrashing.html > [6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-snb5/igt@gem_persistent_relocs@forked-interruptible-thrashing.html > > * igt@gem_ringfill@basic-default-hang: > - shard-glk: [PASS][7] -> [DMESG-WARN][8] ([fdo#110913 > ]) > [7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-glk4/igt@gem_ringfill@basic-default-hang.html > [8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-glk7/igt@gem_ringfill@basic-default-hang.html > > * igt@gem_tiled_swapping@non-threaded: > - shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([fdo#107713] > / [fdo#108686]) > [9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb7/igt@gem_tiled_swapping@non-threaded.html > [10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-iclb2/igt@gem_tiled_swapping@non-threaded.html > - shard-glk: [PASS][11] -> [DMESG-WARN][12] > ([fdo#108686]) > [11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-glk8/igt@gem_tiled_swapping@non-threaded.html > [12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-glk2/igt@gem_tiled_swapping@non-threaded.html > > * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy: > - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([fdo#110913 > ]) > [13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl7/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html > [14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-kbl2/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html > > * igt@i915_suspend@debugfs-reader: > - shard-apl: [PASS][15] -> [DMESG-WARN][16] > ([fdo#108566]) > [15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-apl5/igt@i915_suspend@debugfs-reader.html > [16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-apl1/igt@i915_suspend@debugfs-reader.html > > * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: > - shard-glk: [PASS][17] -> [FAIL][18] ([fdo#104873]) > [17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-glk4/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy.html > [18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-glk9/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy.html > > * igt@kms_frontbuffer_tracking@fbc-stridechange: > - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +4 > similar issues > [19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb1/igt@kms_frontbuffer_tracking@fbc-stridechange.html > [20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-iclb8/igt@kms_frontbuffer_tracking@fbc-stridechange.html > > * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: > - shard-kbl: [PASS][21] -> [DMESG-WARN][22] > ([fdo#108566]) +4 similar issues > [21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl6/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html > [22]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-kbl2/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html > > * igt@kms_plane_lowres@pipe-a-tiling-x: > - shard-iclb: [PASS][23] -> [FAIL][24] ([fdo#103166]) +1 > similar issue > [23]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb3/igt@kms_plane_lowres@pipe-a-tiling-x.html > [24]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-iclb6/igt@kms_plane_lowres@pipe-a-tiling-x.html > > * igt@kms_psr@psr2_no_drrs: > - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109441]) +1 > similar issue > [25]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb2/igt@kms_psr@psr2_no_drrs.html > [26]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-iclb4/igt@kms_psr@psr2_no_drrs.html > > * igt@kms_setmode@basic: > - shard-kbl: [PASS][27] -> [FAIL][28] ([fdo#99912]) > [27]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl1/igt@kms_setmode@basic.html > [28]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-kbl1/igt@kms_setmode@basic.html > > * igt@kms_sysfs_edid_timing: > - shard-iclb: [PASS][29] -> [FAIL][30] ([fdo#100047]) > [29]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb7/igt@kms_sysfs_edid_timing.html > [30]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-iclb2/igt@kms_sysfs_edid_timing.html > > > #### Possible fixes #### > > * igt@gem_ctx_isolation@bcs0-s3: > - shard-kbl: [DMESG-WARN][31] ([fdo#108566]) -> > [PASS][32] +4 similar issues > [31]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl1/igt@gem_ctx_isolation@bcs0-s3.html > [32]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-kbl3/igt@gem_ctx_isolation@bcs0-s3.html > > * igt@gem_eio@in-flight-suspend: > - shard-apl: [DMESG-WARN][33] ([fdo#108566]) -> > [PASS][34] +2 similar issues > [33]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-apl1/igt@gem_eio@in-flight-suspend.html > [34]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-apl3/igt@gem_eio@in-flight-suspend.html > - shard-iclb: [FAIL][35] ([fdo#110667]) -> [PASS][36] > [35]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb8/igt@gem_eio@in-flight-suspend.html > [36]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-iclb3/igt@gem_eio@in-flight-suspend.html > > * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup: > - shard-kbl: [DMESG-WARN][37] ([fdo#110913 ]) -> > [PASS][38] +1 similar issue > [37]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-kbl7/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup.html > [38]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-kbl7/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup.html > - shard-glk: [DMESG-WARN][39] ([fdo#110913 ]) -> > [PASS][40] +1 similar issue > [39]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-glk4/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup.html > [40]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-glk7/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup.html > > * igt@gem_userptr_blits@sync-unmap-cycles: > - shard-snb: [DMESG-WARN][41] ([fdo#110913 ]) -> > [PASS][42] +2 similar issues > [41]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-snb1/igt@gem_userptr_blits@sync-unmap-cycles.html > [42]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-snb2/igt@gem_userptr_blits@sync-unmap-cycles.html > - shard-apl: [DMESG-WARN][43] ([fdo#110913 ]) -> > [PASS][44] +1 similar issue > [43]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-apl3/igt@gem_userptr_blits@sync-unmap-cycles.html > [44]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-apl3/igt@gem_userptr_blits@sync-unmap-cycles.html > > * igt@i915_pm_backlight@fade_with_suspend: > - shard-skl: [INCOMPLETE][45] ([fdo#104108]) -> > [PASS][46] > [45]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-skl3/igt@i915_pm_backlight@fade_with_suspend.html > [46]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-skl8/igt@i915_pm_backlight@fade_with_suspend.html > > * igt@i915_pm_rpm@universal-planes-dpms: > - shard-iclb: [INCOMPLETE][47] ([fdo#107713] / > [fdo#108840]) -> [PASS][48] > [47]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb2/igt@i915_pm_rpm@universal-planes-dpms.html > [48]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-iclb4/igt@i915_pm_rpm@universal-planes-dpms.html > > * igt@kms_cursor_crc@pipe-b-cursor-256x256-onscreen: > - shard-skl: [FAIL][49] ([fdo#103232]) -> [PASS][50] > [49]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-skl1/igt@kms_cursor_crc@pipe-b-cursor-256x256-onscreen.html > [50]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-skl8/igt@kms_cursor_crc@pipe-b-cursor-256x256-onscreen.html > > * igt@kms_flip@flip-vs-expired-vblank-interruptible: > - shard-apl: [FAIL][51] ([fdo#102887] / [fdo#105363]) -> > [PASS][52] > [51]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-apl2/igt@kms_flip@flip-vs-expired-vblank-interruptible.html > [52]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-apl2/igt@kms_flip@flip-vs-expired-vblank-interruptible.html > > * igt@kms > _frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: > - shard-iclb: [FAIL][53] ([fdo#103167]) -> [PASS][54] +3 > similar issues > [53]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb7/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html > [54]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-iclb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html > > * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: > - shard-skl: [FAIL][55] ([fdo#108145]) -> [PASS][56] > [55]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-skl3/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min.html > [56]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-skl1/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min.html > > * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: > - shard-skl: [FAIL][57] ([fdo#108145] / [fdo#110403]) -> > [PASS][58] > [57]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-skl1/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html > [58]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-skl8/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html > > * igt@kms_psr@psr2_sprite_plane_move: > - shard-iclb: [SKIP][59] ([fdo#109441]) -> [PASS][60] +1 > similar issue > [59]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-iclb5/igt@kms_psr@psr2_sprite_plane_move.html > [60]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html > > * igt@kms_setmode@basic: > - shard-skl: [FAIL][61] ([fdo#99912]) -> [PASS][62] > [61]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6277/shard-skl3/igt@kms_setmode@basic.html > [62]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/shard-skl8/igt@kms_setmode@basic.html > > > [fdo#100047]: https://bugs.freedesktop.org/show_bug.cgi?id=100047 > [fdo#102887]: https://bugs.freedesktop.org/show_bug.cgi?id=102887 > [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#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108 > [fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873 > [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363 > [fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411 > [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 > [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145 > [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566 > [fdo#108686]: https://bugs.freedesktop.org/show_bug.cgi?id=108686 > [fdo#108840]: https://bugs.freedesktop.org/show_bug.cgi?id=108840 > [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441 > [fdo#110403]: https://bugs.freedesktop.org/show_bug.cgi?id=110403 > [fdo#110667]: https://bugs.freedesktop.org/show_bug.cgi?id=110667 > [fdo#110789]: https://bugs.freedesktop.org/show_bug.cgi?id=110789 > [fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854 > [fdo#110913 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110913 > [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912 > > > Participating hosts (10 -> 9) > ------------------------------ > > Missing (1): shard-hsw > > > Build changes > ------------- > > * Linux: CI_DRM_6277 -> Patchwork_13297 > > CI_DRM_6277: a0195925ba8732ffae5fed3c0b966ca331bae66c @ > git://anongit.freedesktop.org/gfx-ci/linux > IGT_5057: 3b91c82b90d45c1a30569410c1142b541956740a @ > git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > Patchwork_13297: 1db63f9759d9870782b82bc427aec18aa44c6f5e @ > git://anongit.freedesktop.org/gfx-ci/linux > piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ > git://anongit.freedesktop.org/piglit > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13297/
On 6/25/19 8:26 AM, Matt Roper wrote: > On Fri, Jun 14, 2019 at 03:17:39PM -0700, Matt Roper wrote: >> On Fri, Jun 14, 2019 at 02:37:49PM -0700, José Roberto de Souza wrote: >>> EHL can have up to one VECS(video enhancement) engine, so add it to >>> the device_info. >> >> Bspec 29150 has a footnote on VEbox that indicates "Pass-through only, >> no VEbox processing logic." That note seems a bit vague, but I think I >> saw some more detailed info in the past somewhere that indicated the >> VECS command streamer is still technically present but doesn't actually >> do any video enhancement on EHL; it just passes content through to SFC. >> >> I'm not terribly plugged into the media side of the world, so I'm not >> sure if we want to expose VECS to userspace if it's basically a noop and >> doesn't do what it normally does on other platforms. Bspec page 5229 >> implies that SFC can be fed directly by the decode engine without going >> through VEBOX, so I'm not sure if media userspace would ever have a use >> for the passthrough-only VECS streamer. >> >> We should probably ask someone on the media team what their thoughts are >> on this. > > Since the media team confirmed that there is indeed a use case for a > passthrough-only VECS, > > Reviewed-by: Matt Roper <matthew.d.roper@intel.com> > A bit late for a question, but how does userspace know that this is just a pass-through VECS? Are we expecting them to switch based on platform instead of just using the kernel API? IMO it'd be better to hide the engine in the query ioctl by default and only show it if userspace passes an appropriate flag, otherwise legacy apps could try to submit VECS-specific commands to the engine. Daniele > >> >> >> Matt >> >>> >>> BSpec: 29152 >>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> >>> Cc: Bob Paauwe <bob.j.paauwe@intel.com> >>> Cc: Matt Roper <matthew.d.roper@intel.com> >>> Cc: Clint Taylor <Clinton.A.Taylor@intel.com> >>> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> >>> --- >>> drivers/gpu/drm/i915/i915_pci.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c >>> index 482f1d0f1770..2c5f64ccadb5 100644 >>> --- a/drivers/gpu/drm/i915/i915_pci.c >>> +++ b/drivers/gpu/drm/i915/i915_pci.c >>> @@ -760,7 +760,7 @@ static const struct intel_device_info intel_elkhartlake_info = { >>> GEN11_FEATURES, >>> PLATFORM(INTEL_ELKHARTLAKE), >>> .require_force_probe = 1, >>> - .engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0), >>> + .engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0) | BIT(VECS0), >>> .ppgtt_size = 36, >>> }; >>> >>> -- >>> 2.22.0 >>> >> >> -- >> Matt Roper >> Graphics Software Engineer >> IoTG Platform Enabling & Development >> Intel Corporation >> (916) 356-2795 >> _______________________________________________ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx >
On 25/06/2019 22:48, Daniele Ceraolo Spurio wrote: > On 6/25/19 8:26 AM, Matt Roper wrote: >> On Fri, Jun 14, 2019 at 03:17:39PM -0700, Matt Roper wrote: >>> On Fri, Jun 14, 2019 at 02:37:49PM -0700, José Roberto de Souza wrote: >>>> EHL can have up to one VECS(video enhancement) engine, so add it to >>>> the device_info. >>> >>> Bspec 29150 has a footnote on VEbox that indicates "Pass-through only, >>> no VEbox processing logic." That note seems a bit vague, but I think I >>> saw some more detailed info in the past somewhere that indicated the >>> VECS command streamer is still technically present but doesn't actually >>> do any video enhancement on EHL; it just passes content through to SFC. >>> >>> I'm not terribly plugged into the media side of the world, so I'm not >>> sure if we want to expose VECS to userspace if it's basically a noop and >>> doesn't do what it normally does on other platforms. Bspec page 5229 >>> implies that SFC can be fed directly by the decode engine without going >>> through VEBOX, so I'm not sure if media userspace would ever have a use >>> for the passthrough-only VECS streamer. >>> >>> We should probably ask someone on the media team what their thoughts are >>> on this. >> >> Since the media team confirmed that there is indeed a use case for a >> passthrough-only VECS, >> >> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> >> > > A bit late for a question, but how does userspace know that this is just > a pass-through VECS? Are we expecting them to switch based on platform > instead of just using the kernel API? IMO it'd be better to hide the > engine in the query ioctl by default and only show it if userspace > passes an appropriate flag, otherwise legacy apps could try to submit > VECS-specific commands to the engine. I have a patch which would enable this, guess it's time to send it.. If we go this route (hide the engine by default), this patch would need to add a new capability flag. But what to call it? I915_VIDEO_ENHANCE_CLASS_PASSTHROUGH? Regards, Tvrtko
> -----Original Message----- > From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of Tvrtko > Ursulin > Sent: Tuesday, June 25, 2019 10:22 PM > To: Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com>; Roper, > Matthew D <matthew.d.roper@intel.com>; Souza, Jose <jose.souza@intel.com> > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915/ehl: Add missing VECS engine > > > On 25/06/2019 22:48, Daniele Ceraolo Spurio wrote: > > On 6/25/19 8:26 AM, Matt Roper wrote: > >> On Fri, Jun 14, 2019 at 03:17:39PM -0700, Matt Roper wrote: > >>> On Fri, Jun 14, 2019 at 02:37:49PM -0700, José Roberto de Souza wrote: > >>>> EHL can have up to one VECS(video enhancement) engine, so add it to > >>>> the device_info. > >>> > >>> Bspec 29150 has a footnote on VEbox that indicates "Pass-through only, > >>> no VEbox processing logic." That note seems a bit vague, but I think I > >>> saw some more detailed info in the past somewhere that indicated the > >>> VECS command streamer is still technically present but doesn't actually > >>> do any video enhancement on EHL; it just passes content through to SFC. > >>> > >>> I'm not terribly plugged into the media side of the world, so I'm not > >>> sure if we want to expose VECS to userspace if it's basically a noop and > >>> doesn't do what it normally does on other platforms. Bspec page 5229 > >>> implies that SFC can be fed directly by the decode engine without going > >>> through VEBOX, so I'm not sure if media userspace would ever have a use > >>> for the passthrough-only VECS streamer. > >>> > >>> We should probably ask someone on the media team what their thoughts > are > >>> on this. > >> > >> Since the media team confirmed that there is indeed a use case for a > >> passthrough-only VECS, > >> > >> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> > >> > > > > A bit late for a question, but how does userspace know that this is just > > a pass-through VECS? Are we expecting them to switch based on platform > > instead of just using the kernel API? IMO it'd be better to hide the > > engine in the query ioctl by default and only show it if userspace > > passes an appropriate flag, otherwise legacy apps could try to submit > > VECS-specific commands to the engine. > > I have a patch which would enable this, guess it's time to send it.. > > If we go this route (hide the engine by default), this patch would need > to add a new capability flag. But what to call it? > I915_VIDEO_ENHANCE_CLASS_PASSTHROUGH? I don't get the legacy userspace problem. It's not realistic to expect userspace to 'just work' on new platforms. Instructions are added and removed at each new gen, and umd needs to know that. The capabilities were not really designed to insulate the umd's from making device specific decisions. If umd can easily deduce a capability from the device-id, it should be doing so. The capabilities will become unwieldy very quickly if we start poking in new ones for every change in hardware shape. Caps should be limited to things that cannot be easily deduced, or that can be different on different SKU's of the same device (e.g. fusing). The SFC cap is needed because we don't expose explicit engine numbers to userspace, so it has no easy way to determine which VDBox's have SFC and which do not. Here, we're talking about an easily deducible feature. > > Regards, > > Tvrtko > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c index 482f1d0f1770..2c5f64ccadb5 100644 --- a/drivers/gpu/drm/i915/i915_pci.c +++ b/drivers/gpu/drm/i915/i915_pci.c @@ -760,7 +760,7 @@ static const struct intel_device_info intel_elkhartlake_info = { GEN11_FEATURES, PLATFORM(INTEL_ELKHARTLAKE), .require_force_probe = 1, - .engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0), + .engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0) | BIT(VECS0), .ppgtt_size = 36, };
EHL can have up to one VECS(video enhancement) engine, so add it to the device_info. BSpec: 29152 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> --- drivers/gpu/drm/i915/i915_pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)