multi-planar tiled fourcc's in mesa and drm

[Rob Clark]

So, lucky me, I have a scenario where I get to deal with NV12MT.  Hurray!

I know there has been some reluctance in the past to combine tiling
and color format, since in theory that could lead to a combinatorial
explosion in formats.  And, as long as the buffer usage is entirely
within a single driver, you can approximately hide tiling (or
compressed, etc) permutations of a color format.  On the other hand,
there is already some precedence for fourcc or format values to
represent tiled formats at the interface level (in kernel, v4l, and in
userspace, and gstreamer and openmax).

But in this scenario, sharing buffer between other devices (video
decoder/encoder) and drm/kms (msm) and mesa (freedreno) via
EGL_EXT_image_dma_buf_import[1], I sort of don't really have any other
way to pass around tiling flags.  So I would propose adding custom
fourcc's only in the more limited cases where formats are exchanged
between devices.  This should avoid an explosion of color_format *
tiling_format.

For the kms part, it would mean merging a small patch to allow addfb2
for NV12MT[2].

For the mesa part, it looks like there is a bit of work needed to
teach egl about multi-planar buffers, buffers where offset[n] != 0,
etc.  I'll start with patches to teach egl how to import plain NV12
buffers.  But once that is done, for it to be much use to me I'll need
NV12MT, which means adding a new gallium format and
__DRI_IMAGE_FOURCC_NV12MT.

Also, I'm still a bit undecided on how to represent multi-planar
formats (ie. single pipe_resource encapsulating each of the planes?
or pipe_resource per plane but teach pipe_sampler_view about textures
which have multiple pipe_resource's, one for per plane).

Anyways, I'll start working on the mesa egl bits next week.  First
step is just add an 'offset' parameter to 'struct winsys_handle',
which should hopefully be non-controversial.  After that, I need to
decide how to handle multi-planar, and I think that hinges on how
folks want to handle multi-planar in gallium.  Ie. if one
pipe_resource per plane, then winsys_handle doesn't need any further
change (but we need changes elsewhere), otherwise winsys_handle needs
to have an array of handles.

Anyways, I'd appreciate feedback.

BR,
-R

[1] https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
[2] http://lists.freedesktop.org/archives/dri-devel/2014-July/064828.html