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

[Kenneth Graunke]

On Friday, November 07, 2014 01:52:13 PM Marek Olšák wrote:
> On Fri, Nov 7, 2014 at 1:10 PM, Steven Newbury <steve at snewbury.org.uk> 
wrote:
> > 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.
> 
> Then I'd like those people or companies to speak up.
> 
> I seriously doubt anyone is using OpenVG with a Gallium driver. It
> even needs GL3 hardware (because it uses ARL in a fragment shader).
> That means every non-GL3 Gallium driver has incomplete OpenVG support,
> so OpenVG users should use these: radeon >= r600, nouveau >= nv50, ilo
> maybe? That's it. I wouldn't bother with softpipe and llvmpipe -- if
> you have to use them, you're better off with a VG-over-GL wrapper and
> a good OpenGL driver/hardware combo.
> 
> Marek

It seems like every time we discuss this, there's been the "but we have it" 
argument and one or two people saying "but it would be cool".  But in 
practice, I don't know of anybody even using OpenVG, much less OpenVG on 
Gallium.  People use Cairo or Skia.

It's very clearly not being maintained or developed.  Marek showed data 
indicating no one has worked on it in some time.  Several developers have 
expressed that they would like OpenVG to work with egl_dri2, if we're going to 
keep it at all, and no one has stepped forward to do that work.

Perhaps dropping it would inspire a maintainer to come forward.

--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141107/08b05aac/attachment.sig>