[Intel-gfx] [PATCH] drm/i915/ehl: Add missing VECS engine

[Bloomfield, Jon]

> -----Original Message-----
> From: Intel-gfx <intel-gfx-bounces at lists.freedesktop.org> On Behalf Of Tvrtko
> Ursulin
> Sent: Tuesday, June 25, 2019 10:22 PM
> To: Ceraolo Spurio, Daniele <daniele.ceraolospurio at intel.com>; Roper,
> Matthew D <matthew.d.roper at intel.com>; Souza, Jose <jose.souza at intel.com>
> Cc: intel-gfx at 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 at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx