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

[Marek Olšák]

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