On 05.11.2014 07:42, Marek Olšák wrote:
Hi everybody,I'm about to address this long-standing issue: The EGL state tracker is redundant. It duplicates what st/dri does and it also duplicates what the common loader egl_dri2 does, which is used by all classic drivers and even works better with gallium drivers. Let's compare EGL extensions for both backends: st/egl: EGL version string: 1.4 (Gallium) EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2 OpenVG EGL extensions string: EGL_WL_bind_wayland_display EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_image EGL_KHR_reusable_sync EGL_KHR_fence_sync EGL_KHR_surfaceless_context EGL_NOK_swap_region EGL_NV_post_sub_buffer egl_dri2: EGL version string: 1.4 (DRI2) EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2 OpenGL_ES3 EGL extensions string: EGL_MESA_drm_image EGL_MESA_configless_context EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_surfaceless_context EGL_KHR_create_context EGL_NOK_swap_region EGL_NOK_texture_from_pixmap EGL_CHROMIUM_sync_control EGL_EXT_image_dma_buf_import EGL_NV_post_sub_buffer egl_dri2 also supports MSAA on the window framebuffer (through st/dri). It's really obvious which one is better.
No argument there.
- OpenVG - It has never taken off. If people want this on Linux, it should use egl_dri2 and st/dri, like OpenGL does.
The problem is doing so would probably be a lot of work, so this creates a huge barrier for somebody who wants to play with OpenVG.
How about keeping egl_gallium but only using it if EGL_DRIVER=egl_gallium is specified explicitly? (I assume automatically using egl_gallium for OpenVG isn't possible due to the way EGL works)
-- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
