[Mesa-dev] [RFC-PATCH 00/11] add support for GL_OES_EGL_image_external

[Chia-I Wu]

On Mon, Oct 31, 2011 at 11:46 PM, Eric Anholt <eric at anholt.net> wrote:
> On Mon, 31 Oct 2011 03:07:26 +0800, Chia-I Wu <olvaffe at gmail.com> wrote:
>> From: Chia-I Wu <olv at lunarg.com>
>>
>> Hi,
>>
>> This patch series adds support for the OpenGL ES specific
>> GL_OES_EGL_image_external extension[1].  It is enabled in st/mesa.
>
>> The extension is written with YUV formats in mind.  It describes two possible
>> ways to to support them.  One is to insert extra instructions to the shaders
>> to let GPU perform the necessary color conversions on the fly.  The other is
>> to allocate an internal storage to perform the conversions when the EGLImage
>> is specified.  Neither is supported for this series.  It effectively makes the
>> implementation a subset of GL_OES_EGL_image function-wise.
>
> Both of these options are why I hated the idea of this extension.
>
> If the application wants to do YUV conversion, it should be doing YUV
> conversion.  We give them access to shaders for a reason.  Hiding the
> interaction between planar YUV and actual texture units is going to be
> miserable.
I agree.  But I think the design of this extension just chooses a
clean, maybe oversimplified, API over a clean implementation.

EGLImage is designed to be a completely opaque object.  Its pixel
format or any other property is unknown and unknownable.  To be able
to sample from an EGLImage, you either define the return values to be
always RGBA as is done in this extension, or to export its pixel
format in some sense after it is bound to a texture.  The former
leaves the mess to the driver.  Real mess.  The latter leaves the mess
to the extension spec and apps, in that every OS or mobile device may
theoretically have an extension for its formats of choice, and the
apps need to handle them.  (But as we know it, there may only be two,
RGBA-based or YUV-based, ever.)

The fact that the current extension allows the color conversions to be
done at bound time allows an implementation to support it in the
winsys code.  Say, Android supports the planar YV12 with its special
requirement for plane memory alignments.  We do not want to know about
that in core mesa or drivers.  But we know that and can handle that in
the Android-specific glue code in EGL.

-- 
olv at LunarG.com