[Mesa-dev] [PATCH 4/4] egl/dri2: add image extension to swrast_core_extensions

[Emil Velikov]

On 9 June 2017 at 16:40, Gurchetan Singh <gurchetansingh at chromium.org> wrote:
> Actually, these are the only patches that are required.  We're trying to run
> the Android Studio emulator using the host's GLES implementation.  The
> emulator uses the image extension in that case:
>
> https://android.googlesource.com/platform/sdk/+/emu-2.4-release/emulator/opengl/host/libs/libOpenglRender/FrameBuffer.cpp
> https://android.googlesource.com/platform/sdk/+/emu-2.4-release/emulator/opengl/host/libs/libOpenglRender/ColorBuffer.cpp
>
> It does only use a subset of the extension, but nothing hardware specific.
>
True, there's nothing HW specific, yet it does DRM specifics ;-)

>From a quick look, all one needs to do is add kms_swrast support in
EGL analogous to GBM [1].
On the cool side, I've spotted a few (too many) bugs that we want to
address. I can tackle the Mesa ones [2], but please give the
emulator/qemu ones a try [3].

Thanks
Emil

[1] git show 3b176c441b7ddc5f7d2f891da3f76cf3c1814ce1  -- src/gbm/

[2] Mesa side
 - dozen or so missed checks for EGL_KHR_gl_texture_*_image extension caps

[3] The emulator code - seems to be moved to qemu/distrib/android, so
I'll omit the ones in the original sdk codebase ;-)
- query for ES1 extensions and assume that the ES2 context will have
the same ones
- error out if no ES1 configs are found - we don't care about those
since only ES2 are used
In general it seems like someone started ripping out ES1 support, but
did not quite complete it, pulling some ES2 bits by mistake. Having a
grep for s_gles1 and working up might be a good idea.

- has_eglimage_texture_2d can never be false, yet
ColorBuffer::create() takes it as an argument. In the unlikely case
that the extension is missing, function does a some setup, only to
_not_ create any images as needed later on.
- using strstr for checking extension presence is flawed.
For example: It will give false positives for OES_EGL_image_external
and OES_EGL_image_external_essl3 when one is interested in
OES_EGL_image. Disclaimer: I haven't checked if the alternative
extensions provide the required functionality.
- EGL_KHR_gl_renderbuffer_image is unused, yet checked