Ok, so the basic problem with the YUV tests is that they currently
completely ignore driver/hw pitch requirements, since the code that
allocates the buffer doesn't know the pixel format, only the 'cpp'.

The yuv test creates a small 4x4 yuv eglimage.  If, say, the hardware
requires the pitch to be aligned to, say, 32pixels, everything is fine
for the Y plane, but the subsampled U/V or U+V plane has half as many
pixels.  (This did help me catch a bug in driver, not rejecting the
dmabuf import with invalid pitch, but that doesn't help to get the
piglit tests running.)

The best approach I could come up with to fix this is to pass the
fourcc all the way down to the code that creates the dmabuf (and copies
src data into the dmabuf).  Unfortunately this makes the patch a bit
bigger than I was hoping, and not really sure a good way to split it
up.

This is tested on i965 (with the intel dma-buf backend) and freedreno
(with the gbm dma-buf backend).  In the gbm case, it requires new
gbm format values for R8 and GR88, which is on mesa master as of
this morning.  (So I bumped the gbm version dependency to 12.1.)

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>