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

[Chia-I Wu]

On Mon, Oct 31, 2011 at 10:16 PM, Jakob Bornecrantz <jakob at vmware.com> wrote:
> ----- Original Message -----
>> 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 adds a new texture target, GL_TEXTURE_EXTERNAL_OES.  It
>> can only be specified with an EGLImage.  Calling gl*Tex*Image* to
>> manipulate an external texture will result in GL_INVALID_ENUM.
>> Because of the restrictions, it allows formats that are not otherwise
>> supported to be sampled from.
>>
>> 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.
>>
>> Later, I plan to adopt the latter, also easier, approach to support
>> NV21 and YV12 formats[2] (for Android, but haven't started).  The
>> changes will be limitied to the winsys code.  The idea is that the
>> pixel format of an EGLImage is winsys dependent.  There are too
>> many formats, well defined or not, to be enumerated in pipe_format
>> or gl_format.
>>
>> This series is tested with piglit quick.tests on i965 and llvmpipe
>> without regressions.  I am unfamiliar with more than a couple of
>> areas touched by this series.  Comments are appreciated.
>
> Cool stuff! How hard would it be to add this to Desktop GL? I'm
> guessing it is slightly more involved then changing patch 06 and 11 to
> enable the it for Desktop GL?
Ignoring YUV formats, this extension achieves the same thing as
GL_OES_EGL_image does, which we already advertise for desktop GL (for
Wayland IIRC).  But the fact that it defines a new texture target
makes some interactions with desktop GL undefined, as Ian mentioned.

> Took a quick look at it and it looks good, but I don't dare give it a
> RB so you can have my
> Acked-by: Jakob Bornecrantz <jakob at vmware.com>
>
> Cheers, Jakob.
>



-- 
olv at LunarG.com