On Sun, Jan 31, 2016 at 5:24 PM, Rob Herring <r...@kernel.org> wrote: > On Fri, Jan 29, 2016 at 4:37 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> 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. > > 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.
Either way, make sure to expose the ext string for the relevant exts... I unfortunately don't know enough about EGL and all the things these exts are trying to address to be able to provide actual feedback on your reasoning, sorry. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
