On Fri, Nov 7, 2014 at 1:10 PM, Steven Newbury <st...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev