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@xxxxxxxxx> > 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@xxxxxxxxx> 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:
pgpGFaxsNdpWU.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
