Re: [RFC PATCH 0/3] drm driver for baytrail's vxd392

[Thierry Reding <thierry.reding@gmail.com>]

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

On Wed, Oct 15, 2014 at 01:18:02AM -0700, Stéphane Marchesin wrote:
> On Wed, Oct 15, 2014 at 1:13 AM, Thierry Reding <thierry.reding@gmail.com>
> wrote:
> 
> > On Tue, Oct 14, 2014 at 08:50:35AM -0700, Sean V Kelley wrote:
> > > On Tue, Oct 14, 2014 at 4:53 AM, Thierry Reding
> > > <thierry.reding@gmail.com> wrote:
> > > > On Mon, Oct 13, 2014 at 08:15:00PM +0800, Yao Cheng wrote:
> > > >> drm/ipvr is a new GEM driver for baytrail's vxd392, which accelerates
> > VP8 video decoding.
> > > >> The driver name "ipvr" means the PowerVR's IP wrapped by Intel. In
> > the future, ipvr may support other platforms such as Merrifield.
> > > >> Code is placed at drivers/gpu/drm/ipvr and the following two new
> > Kconfig are added:
> > > >>   CONFIG_DRM_IPVR: Build option for ipvr module
> > > >>   CONFIG_DRM_IPVR_EC: Experimental feature of error concealment
> > > >>
> > > >> User mode drm helper "libdrm_ipvr.so" and simple test are also
> > included.
> > > >>
> > > >> Yao Cheng (3):
> > > >>  [1/3] drm/i915: add vxd392 bridge in i915 on baytrail
> > > >>  [2/3] drm/ipvr: ipvr drm driver for vxd392
> > > >
> > > > If this is Intel-specific, why doesn't it live under the i915 driver?
> > >
> > > It is an entirely unrelated HW IP block, VXD392.  Nothing to do with
> > > GEN aside from DRM based.
> >
> > With GEN you're referring to the Intel integrated GPU? And VXD392 I take
> > it is the IP block licensed by Imagination? Baytrail and others then
> > wrap some additional logic around this as it is integrated into the SoC?
> >
> > How much wrapping actually happens here? I worry that this is going to
> > lead to a lot of duplication if we ever want to support another SoC that
> > uses the VXD392 IP. Could the code be split into a VXD392 "library" and
> > some driver that implements the Intel-specific glue?
> >
> > Finally, if this IP block is a VP8 video decoding engine only, I'm not
> > sure DRM is the best subsystem for it. Traditionally video decoding has
> > been done primarily in V4L2. I'm not sure that's the best fit given that
> > it was originally designed for video capturing, but they've evolved some
> > infrastructure to deal with encoding/decoding, whereas we have nothing
> > like that at all in DRM.
> >
> 
> That isn't true. i915, nouveau and radeon drm drivers all support video
> decoding user space in some form.

Well yes, because they are GPUs that happen to have video decoding
engines on the same board and use the same method of command-stream
submission that they use for 2D or 3D work.

For standalone video decoding hardware, the only drivers that I know of
are in drivers/media.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx