[Mesa-dev] [PATCH 1/8] __DRIimage: version 5, add new formats and createSubImage

[Eric Anholt]

Kristian Høgsberg <krh at bitplanet.net> writes:

> The additions in version 5 enables creating EGLImages for different planes
> of a YUV buffer.  createImageFromName is still used to create the containing
> __DRIimage, and createSubImage can then be used no that __DRIimage to create
> __DRIimages that correspond to the y, u, and v planes (__DRI_IMAGE_FORMAT_R8)
> or the uv planes (__DRI_IMAGE_FORMAT_RG88) for formats such as NV12 where
> the u and v components are interleaved.  Packed formats such as YUYV etc
> doesn't require any special treatment, we just sample those as a regular
> ARGB texture.

This patch series is making more sense to me than the last few yuv
patchsets I've seen.

> Signed-off-by: Kristian Høgsberg <krh at bitplanet.net>
> ---
>  include/GL/internal/dri_interface.h |   16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>
> diff --git a/include/GL/internal/dri_interface.h b/include/GL/internal/dri_interface.h
> index e37917e..5dfe15b 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -907,6 +907,10 @@ struct __DRIdri2ExtensionRec {
>  #define __DRI_IMAGE_FORMAT_ARGB8888     0x1003
>  #define __DRI_IMAGE_FORMAT_ABGR8888     0x1004
>  #define __DRI_IMAGE_FORMAT_XBGR8888     0x1005
> +#define __DRI_IMAGE_FORMAT_R8           0x1006 /* Since version 5 */
> +#define __DRI_IMAGE_FORMAT_RG88         0x1007
> +#define __DRI_IMAGE_FORMAT_YUV420       0x1008
> +#define __DRI_IMAGE_FORMAT_NV12         0x1009

Could we get just a couple notes on the yuv420/nv12 formats here?  Also,
can one of these end up as an OES_EGL_image that someone might try to
bind as a texture?  What should happen, if so?  (If it's possible, the
MESA_FORMAT_NONE in the next patch would result in a bunch of
_mesa_problem()s and failure)

>  #define __DRI_IMAGE_USE_SHARE		0x0001
>  #define __DRI_IMAGE_USE_SCANOUT		0x0002
> @@ -963,6 +967,18 @@ struct __DRIimageExtensionRec {
>      * \since 4
>      */
>     int (*write)(__DRIimage *image, const void *buf, size_t count);
> +
> +   /**
> +    * Create an image out of a sub-region of a parent image.  This
> +    * entry point lets us create individual __DRIimages for different
> +    * planes in a planar buffer (typically yuv), for example.
> +    *
> +    * \since 5
> +    */
> +    __DRIimage *(*createSubImage)(__DRIimage *image,
> +                                  int width, int height, int format,
> +                                  int offset, int pitch,
> +                                  void *loaderPrivate);
>  };

Some notes about lifetime would be good here.  In the implementation you
have, the subimage gets separated from the parent, so changing the
storage of the parent (if that's a thing that's possible -- I don't
understand egl image lifetimes) wouldn't be tracked in the child.  You
could free the parent safely, as well.

If the subimage can get bound as a render target, it won't be reliably
synchronized with texturing from another subimage that overlaps it, and
that seems like something to be noted.

Are there supposed to be any restrictions on the layout of
width/height/offset/pitch related to the parent?  For tiled buffers,
there would be.  Is this totally driver-dependent?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120706/b4efca0b/attachment.pgp>