[Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds

Steven Newbury steve at snewbury.org.uk
Fri Nov 7 04:10:47 PST 2014


On Wed, 2014-11-05 at 00:46 +0000, Emil Velikov wrote:
> On 04/11/14 22: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.
> > 
> > I'm aware of 2 features that we will lose:
> > - swrast on Wayland - I'm not sure about this. Perhaps kms-swrast 
> > has
> > addressed this already.
> > - OpenVG - It has never taken off. If people want this on Linux, 
> > it should
> > use egl_dri2 and st/dri, like OpenGL does.
> > 
I think it would be a shame to lose the OpenVG backend.  It's been 
disappointing with the lack of interest on desktop systems even 
through cairo, but I wonder if it was because of the inherent Gallium 
only nature?  Cairo's GL backend is probably more likely to work on 
more systems because of this.  Admittedly, it was probably mostly 
useful as a technology on weaker CPUs and simpler GPUs without full 
OpenGL(ES) capability where it could provide a performant GUI.

> > T his series removes st/egl and st/gbm support from the autoconf 
> > build (the latter depends on the former and is probably just as 
> > redundant). The next step is to remove all Linux-specific backends 
> > from st/egl. Windows, Android, and other platform backends will be 
> > kept intact, therefore st/egl won't be removed completely.
> > 
> > Please comment.
> > 
I use EGL_DRIVER=egl_gallium to switch to using the ilo driver at run-
time.  (Admittedly, mostly for testing more than anything useful.)  
There would have to be some other way of at least selecting run-time 
backend to egl_dri2 for this functionality to continue working.

> A few thoughts:
>  - Iirc Eric is using st/egl as the dri2 backend seems to be causing
> problems :(
>  - Android supports dri modules, but st/dri/Android.mk is missing.
> Should be trivial to add.
>  - Windows - might be a pain in the a** to get it working. Then again
> does Windows have EGL ?
>  - fbdev, OpenVG - the etnaviv project was using the former, 
> currently
> moving to full-blown drm :)
> 
> If one is to nuking the three st we can remove
>  - the libEGL symbol export mayhem
>  - gallium's st_api, and flatten things a bit
>  - a bit of duplication :)
> 
> In summary:
> With a bit of work we can remove Linux and Android from the 
> equation. How many people/companies use EGL for Windows/fbdev, how 
> about OpenVG on any platform ?
> 
I'm not sure we can know how many use OpenVG.  Probably more than is 
commonly thought on this list.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141107/124e0aa8/attachment-0001.sig>


More information about the mesa-dev mailing list