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

[Pekka Paalanen]

On Tue,  4 Nov 2014 23:42:43 +0100
Marek Olšák <maraeo at gmail.com> 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 am slightly surprised you do not get EGL_WL_bind_wayland_display on
DRI2. Wonder why that is...

Other things not in your dri2 that are in gallium are KHR_reusable_sync
and KHR_fence_sync. Does that matter?

> 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.

I don't think it does.

Isn't kms-swrast about the EGL DRM/KMS platform but using dumb buffers
with software rendering instead of real acceleratable buffers?
That is, it could be used by Wayland display servers, but not
Wayland apps.

I don't think that has anything to do with the EGL Wayland platform
that is used by applications on Wayland. I am not aware of anything
else than egl_gallium.so implementing the glue for doing software
rendering into wl_shm-based buffers, which do not need *any* special
support from the display server. This means that the server does not
need to use EGL at all while still supporting software-GL in apps.

It also allows one to use a non-Wayland supporting EGL implementation
to accelerate compositing in the server, while still supporting
software rendered GL apps.

In other words, I believe that removing egl_gallium.so will prevent
running GL apps on Wayland with software-GL, like you suspected.

I'm not sure how used that is, but every once in a while I explain to
someone how to get software-GL going, so I would expect a few upset
people from that.

I have no clue what it would take to support swrast via wl_shm on EGL
Wayland platform with egl_dri2. I tried to ask if the kms-swrast made
that any easier, but I was left with the feeling that it doesn't.
Swrast on wl_shm would be the sensible thing, but swrast on DRM buffers
on Wayland platform would probably be useless, at least until we have a
generic dmabuf protocol in place (which is a whole another saga with
no end in sight), and it would still explicitly depend on DRM.

Personally I like the idea of getting rid of egl_gallium.so, but indeed
we do lose some things if that is done right now. Or maybe this would
be the kick needed to have someone look at implementing wl_shm support
for swrast in egl_dri2...


Thanks,
pq

> - OpenVG - It has never taken off. If people want this on Linux, it should
> use egl_dri2 and st/dri, like OpenGL does.
> 
> This 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.