On Fri, Jan 29, 2016 at 5:18 PM, Rob Herring <r...@kernel.org> wrote:
> On Fri, Jan 29, 2016 at 3:46 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>> On Fri, Jan 29, 2016 at 4:41 PM, Rob Herring <r...@kernel.org> wrote:
>>> On Fri, Jan 29, 2016 at 3:05 PM, Ilia Mirkin <imir...@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.
-ilia
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
