[Mesa-dev] [PATCH 2/5] egl: Add EGL_RECORDABLE_ANDROID attribute

[Rob Herring]

On Fri, Jan 29, 2016 at 4:37 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Fri, Jan 29, 2016 at 5:18 PM, Rob Herring <robh at kernel.org> wrote:
>> On Fri, Jan 29, 2016 at 3:46 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>> On Fri, Jan 29, 2016 at 4:41 PM, Rob Herring <robh at kernel.org> wrote:
>>>> On Fri, Jan 29, 2016 at 3:05 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>>> Both for this and the previous patch, should we start advertising the
>>>>> relevant EGL extensions as well? Or would that take more effort than
>>>>> just not returning errors for them?
>>>>
>>>> That is what patch 5 does. It seems to work just advertising the extensions.
>>>
>>> Patch 5 just adds those enums somewhere. I meant something like
>>> _eglCreateExtensionsString which would expose the relevant extensions
>>> as supported.
>>
>> Okay, got it. I can look at adding that part. Maybe we don't want to
>> advertise it until fully supported? I'm not really sure, so any
>> guidance here is helpful.
>
> Right, well you shouldn't be adding the enums without actually
> supporting the ext... I haven't looked at those ext's in detail
> though.
>
>>
>> I guess that would make the extensions show-up in this listing:
>>
>> 01-29 22:10:00.272  1083  1083 I SurfaceFlinger: OpenGL ES informations:
>> 01-29 22:10:00.272  1083  1083 I SurfaceFlinger: vendor    : Red Hat
>> 01-29 22:10:00.272  1083  1083 I SurfaceFlinger: renderer  : Gallium
>> 0.4 on virgl
>> 01-29 22:10:00.272  1083  1083 I SurfaceFlinger: version   : OpenGL ES
>> 3.0 Mesa 11.2.0-devel (git-045d7bb)
>> 01-29 22:10:00.272  1083  1083 I SurfaceFlinger: extensions:
>> GL_EXT_debug_marker GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
>> GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888
>> GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24
>> GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer
>> GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_stencil8
>> GL_OES_texture_3D GL_OES_texture_float GL_OES_texture_half_float
>> GL_OES_texture_npot GL_OES_EGL_image GL_OES_depth_texture
>> GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV
>> GL_OES_get_program_binary GL_APPLE_texture_max_level
>> GL_EXT_discard_framebuffer GL_EXT_read_format_bgra
>> GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync
>> GL_OES_vertex_array_object GL_EXT_texture_rg GL_EXT_unpack_subimage
>> GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth
>> GL_NV_read_depth_stencil GL_NV_read_stencil GL_EXT_draw_buffers
>> GL_EXT_map_buffer_range GL_KHR_debug GL_OES_depth_texture_cube_map
>> GL_OES_surfaceless_context GL_EXT_color_buffer_float
>> GL_EXT_separate_shader_objects GL
>
> No, those are the GL exts (hence GL_bla). You want the EGL exts. For
> example on my box:
>
> $ eglinfo
> EGL API version: 1.4
> EGL vendor string: Mesa Project
> EGL version string: 1.4 (DRI2)
> EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2 OpenGL_ES3
> EGL extensions string:
>     EGL_CHROMIUM_sync_control EGL_EXT_create_context_robustness
>     EGL_EXT_image_dma_buf_import EGL_KHR_create_context
>     EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses
>     EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image
>     EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base
>     EGL_KHR_image_pixmap EGL_KHR_surfaceless_context EGL_KHR_wait_sync
>     EGL_MESA_configless_context EGL_MESA_drm_image
>     EGL_MESA_image_dma_buf_export EGL_NOK_swap_region
>     EGL_NOK_texture_from_pixmap EGL_NV_post_sub_buffer
>
> The recordable bit is defined in EGL_ANDROID_recordable
> (https://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt).
> It seems like a valid implementation is to always report it as "not
> recordable" :) I have no idea about all this shared junk though,
> sorry.

One possible implementation according to the doc is that the encoder
has to support RGB inputs. RGB is also the only native window format
supported in mesa. So I think we just assume that is the
implementation mesa supports. If there are only a subset of RGB input
formats supported though, I don't see how the EGL can know what the
encoder restrictions are.

For the framebuffer target, it is supposed to be the formats the HWC
supports. I think you could assume that is any supported scanout
format the DRM device supports. That is already being done for the egl
config creation, so I think just setting the property to true is okay
for the implementation. Similarly to the encoder case, if the HWC had
different requirements, I'm not sure how the EGL implementation can
know that.

Rob