Re: [PATCH] drm/i915/ehl: Add missing VECS engine

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxxx>


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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux