On Fri, Mar 30, 2012 at 08:07:16PM +0900, 김승우 wrote:
> Hi Ville,
>
> I skipped explanation about NV12M and other two formats because these
> formats are already in kernel drm_fourcc.h.
>
> I think it is better to add a difference between NV12 and NV12M here.
>
> NV12M has Y plane and CbCr plane and these are in non contiguous memory
> region. Compared with NV12, NV12M's memory shape is like following.
> NV12 : ______(Y)(CbCr)_______
> NV12M : __(Y)_ ..... _(CbCr)__
>
> Y and CbCr plane of NV12 can be expressed with one memory address and
> offset of each plane. but NV12M needs memory address of each plane.
Yes, I know the difference between NV12 and NV12M. But that doesn't
change the fact that you can already represent NV12M with
DRM_FORMAT_NV12 (hint handles[], offsets[]). Maybe I should have named
it DRM_FORMAT_YUV420_2P or something like that. Anyone have a time
machine I could borrow?
> On 2012년 03월 30일 19:12, Ville Syrjälä wrote:
> > On Fri, Mar 30, 2012 at 11:54:50AM +0900, Seung-Woo Kim wrote:
> >> Multi buffer plane pixel formats are added as like kernel header.
> >>
> >> Signed-off-by: Seung-Woo Kim<sw0312....@samsung.com>
> >> ---
> >> include/drm/drm_fourcc.h | 7 +++++++
> >> 1 files changed, 7 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> >> index 85facb0..7cfd95a 100644
> >> --- a/include/drm/drm_fourcc.h
> >> +++ b/include/drm/drm_fourcc.h
> >> @@ -107,6 +107,10 @@
> >> #define DRM_FORMAT_NV16 fourcc_code('N', 'V', '1', '6') /* 2x1
> >> subsampled Cr:Cb plane */
> >> #define DRM_FORMAT_NV61 fourcc_code('N', 'V', '6', '1') /* 2x1
> >> subsampled Cb:Cr plane */
> >>
> >> +/* 2 non contiguous plane YCbCr */
> >> +#define DRM_FORMAT_NV12M fourcc_code('N', 'M', '1', '2') /* 2x2
> >> subsampled Cr:Cb plane */
> > NAK. DRM_FORMAT_NV12 handles this just fine.
> >
>
> Exynos soc supports two kinds of memory shape explained above, so two
> different types are need for exynos soc.
>
> >> +#define DRM_FORMAT_NV12MT fourcc_code('T', 'M', '1', '2') /* 2x2
> >> subsampled Cr:Cb plane 64x32 macroblocks */
> > This one is more difficult. Until now tiling was always handled in
> > driver specific manner. OTOH if this format is really supported by
> > different devices from multiple vendors, then it would probably
> > make sense to add it as a standard format.
> >
> Exynos soc also supports normal and tiled pixel data and pixel data is
> shared
> between hw blocks for example from scaler to hdmi.
> So driver can not handle it internally.
If it's all in one driver, it surely can. And even with multiple drivers
you could still pass that information via some kernel internal mechanism.
I'm not opposed to supporting such layouts, but I'm just worried that
tomorrow someone comes up a new device that supports 100 new tiling
layouts for some format, and then we need to add all of them as separate
DRM_FORMATs. And there is already plenty of hardware out there that can
do different tiled layouts to yours, in fact I have some on my desk even
now.
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
