Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
FYI, I've pushed these patches. Marek On Fri, Nov 14, 2014 at 3:51 PM, Jose Fonseca wrote: > I googled and tried to find any evidence of anybody using Mesa's EGL on > Windows over the last years but couldn't. > > Furthermore since my last reply on this thread I become quite fond of > GLX/WGL_EXT_create_context_es/es2_profile extensions. They seem a much easier > mechanism to use and test OpenGL ES contexts, than dealing with EGL on > desktop OSes (and the ensuing interactions between EGL + GLX/WGL). > > I still suspect EGL outside Linux+DRI will have a future, but I don't feel > strongly about it anymore. So feel free to remove whatever you want (st/egl, > openvg) as far as I'm concerned. We can always bring it back later from git > history. > > Jose > > > From: Emil Velikov > Sent: 14 November 2014 14:08 > To: Eric Anholt; Marek Olšák; mesa-dev@lists.freedesktop.org > Cc: emil.l.veli...@gmail.com; Jose Fonseca > Subject: Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for > Linux/DRI builds > > On 05/11/14 20:39, Eric Anholt wrote: >> Marek Olšák writes: >> >>> 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: >> >> I'd love to see VG get nuked at the same time, but still: >> >> Reviewed-by: Eric Anholt >> > Ideally yes. Yet with this series we error out, which should give > insensitive for someone to come forward and implement the missing bits. > > So can we consider Jose's statement [1] as acked-by and get this in for > 10.4 ? Or are we going to keep the zombie for another XXX months ? > > Jose ? > > Cheers > Emil > > [1] "In short, stop caring about st/egl on Linux, maybe even remove DRI > support out st/egl if you must, but please don't go out of your way to > break EGL on non-linux platforms." ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
I googled and tried to find any evidence of anybody using Mesa's EGL on Windows over the last years but couldn't. Furthermore since my last reply on this thread I become quite fond of GLX/WGL_EXT_create_context_es/es2_profile extensions. They seem a much easier mechanism to use and test OpenGL ES contexts, than dealing with EGL on desktop OSes (and the ensuing interactions between EGL + GLX/WGL). I still suspect EGL outside Linux+DRI will have a future, but I don't feel strongly about it anymore. So feel free to remove whatever you want (st/egl, openvg) as far as I'm concerned. We can always bring it back later from git history. Jose From: Emil Velikov Sent: 14 November 2014 14:08 To: Eric Anholt; Marek Olšák; mesa-dev@lists.freedesktop.org Cc: emil.l.veli...@gmail.com; Jose Fonseca Subject: Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds On 05/11/14 20:39, Eric Anholt wrote: > Marek Olšák writes: > >> 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: > > I'd love to see VG get nuked at the same time, but still: > > Reviewed-by: Eric Anholt > Ideally yes. Yet with this series we error out, which should give insensitive for someone to come forward and implement the missing bits. So can we consider Jose's statement [1] as acked-by and get this in for 10.4 ? Or are we going to keep the zombie for another XXX months ? Jose ? Cheers Emil [1] "In short, stop caring about st/egl on Linux, maybe even remove DRI support out st/egl if you must, but please don't go out of your way to break EGL on non-linux platforms." ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
On 05/11/14 20:39, Eric Anholt wrote: > Marek Olšák writes: > >> 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: > > I'd love to see VG get nuked at the same time, but still: > > Reviewed-by: Eric Anholt > Ideally yes. Yet with this series we error out, which should give insensitive for someone to come forward and implement the missing bits. So can we consider Jose's statement [1] as acked-by and get this in for 10.4 ? Or are we going to keep the zombie for another XXX months ? Jose ? Cheers Emil [1] "In short, stop caring about st/egl on Linux, maybe even remove DRI support out st/egl if you must, but please don't go out of your way to break EGL on non-linux platforms." ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
On Friday, November 07, 2014 01:52:13 PM Marek Olšák wrote: > On Fri, Nov 7, 2014 at 1:10 PM, Steven Newbury wrote: > > On Wed, 2014-11-05 at 00:46 +, 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 dev
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
On Fri, Nov 7, 2014 at 1:10 PM, Steven Newbury wrote: > On Wed, 2014-11-05 at 00:46 +, 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
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
On Wed, 2014-11-05 at 00:46 +, 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. signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
On 05/11/14 21:11, Jose Fonseca wrote: >> How many people/companies use EGL for Windows/fbdev, how about OpenVG on > any platform ? > > I already said this privately to Marek when he was RFC'ing on this change: > I'm fine if Linux-specific drivers abandon st/egl to focus solely on st/dri, > but removing st/egl altogether seems unnecessary and short-sighted: EGL is a > cross-platform API, Mesa is a cross-platform implementation of OpenGL and > friends, so sooner or later people will want to have Mesa's EGL support on > platforms others than Linux. > > This is not hypothetical: > - See https://bugs.freedesktop.org/show_bug.cgi?id=40920 for an example of a > bug reported from an user using llvmpipe + egl + opengv on windows. > - VMware doesn't currently ship or support EGL on Windows, but I suspect we > eventually we'll want to support EGL on non-linux platforms. > > Even if OpenVG is loosing popularity, but maybe Khronos will come up with > another cross-platform graphics API (maybe OpenGL NG) that's tied to EGL. > > So a cross-platform implementation of EGL is bound to be useful. > > > I don't test, but I build egl-static and OpenVG on Windows nightly w/ > llvmpipe. It's like a superset of OSMesa, and it seems more useful, as it > gives one more APIs than OSMesa, and through a standard API to create/bind > contexts . > > > In short, stop caring about st/egl on Linux, maybe even remove DRI support > out st/egl if you must, but please don't go out of your way to break EGL on > non-linux platforms. > So let me justify why I brought this in the first place: 1. Over the last two years st/egl had the following patches * Build fixes & related - most of the patches (80%?) * Interface changes - ~10 patches * Bugfixes - ~3 patches * New "features" - 1 patch (already present with the dri2 backend) 2. Over the last two years I've not seen any bug reports from people using either st/egl or st/vega. Must admit I was not looking too closely. 3. Afaict the VMWare or other commercial products do not use it. So based on those my naive question was "Is there anyone actually using those state-trackers, rather than just building them" - i.e. it was meant as a question, rather than a message of hate wrt the code-base :-) I must admit I cannot predict the future (i.e. what VMWare, Khronos and/or others have in plan) but based on the lack of testers, maintainers and new improvements imho it make sense to remove the stale code. As soon as any of that changes we can always bring it back. So I would not call it short-sighted, but imho it does not make sense to cling onto something in the hopes that one day someone may use it. Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
On Wed, Nov 5, 2014 at 6:42 AM, 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. > > 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. While I think Pekka and Jose have valid arguments, I am not sure if anyone is taking care of st/egl bug reports and patch reviews. If no one is, it might be better for st/egl to go than to stay IMHO. > > Please comment. > > Thanks, > > Marek > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
On Thu, Nov 6, 2014 at 5:11 AM, Jose Fonseca wrote: >> How many people/companies use EGL for Windows/fbdev, how about OpenVG on > any platform ? > > I already said this privately to Marek when he was RFC'ing on this change: > I'm fine if Linux-specific drivers abandon st/egl to focus solely on st/dri, > but removing st/egl altogether seems unnecessary and short-sighted: EGL is a > cross-platform API, Mesa is a cross-platform implementation of OpenGL and > friends, so sooner or later people will want to have Mesa's EGL support on > platforms others than Linux. > > This is not hypothetical: > - See https://bugs.freedesktop.org/show_bug.cgi?id=40920 for an example of a > bug reported from an user using llvmpipe + egl + opengv on windows. > - VMware doesn't currently ship or support EGL on Windows, but I suspect we > eventually we'll want to support EGL on non-linux platforms. > > Even if OpenVG is loosing popularity, but maybe Khronos will come up with > another cross-platform graphics API (maybe OpenGL NG) that's tied to EGL. > > So a cross-platform implementation of EGL is bound to be useful. > > > I don't test, but I build egl-static and OpenVG on Windows nightly w/ > llvmpipe. It's like a superset of OSMesa, and it seems more useful, as it > gives one more APIs than OSMesa, and through a standard API to create/bind > contexts . EGL/OpenVG worked with softpipe at one point on Windows. I am not sure about the status now. > > > In short, stop caring about st/egl on Linux, maybe even remove DRI support > out st/egl if you must, but please don't go out of your way to break EGL on > non-linux platforms. > > > Jose > > > From: mesa-dev on behalf of Emil > Velikov > Sent: 05 November 2014 00:46 > To: Marek Olšák; mesa-dev@lists.freedesktop.org > Cc: emil.l.veli...@gmail.com > Subject: Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for > Linux/DRI builds > > 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. >> >> 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. >> >> Please comment. >> > 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
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
> How many people/companies use EGL for Windows/fbdev, how about OpenVG on any platform ? I already said this privately to Marek when he was RFC'ing on this change: I'm fine if Linux-specific drivers abandon st/egl to focus solely on st/dri, but removing st/egl altogether seems unnecessary and short-sighted: EGL is a cross-platform API, Mesa is a cross-platform implementation of OpenGL and friends, so sooner or later people will want to have Mesa's EGL support on platforms others than Linux. This is not hypothetical: - See https://bugs.freedesktop.org/show_bug.cgi?id=40920 for an example of a bug reported from an user using llvmpipe + egl + opengv on windows. - VMware doesn't currently ship or support EGL on Windows, but I suspect we eventually we'll want to support EGL on non-linux platforms. Even if OpenVG is loosing popularity, but maybe Khronos will come up with another cross-platform graphics API (maybe OpenGL NG) that's tied to EGL. So a cross-platform implementation of EGL is bound to be useful. I don't test, but I build egl-static and OpenVG on Windows nightly w/ llvmpipe. It's like a superset of OSMesa, and it seems more useful, as it gives one more APIs than OSMesa, and through a standard API to create/bind contexts . In short, stop caring about st/egl on Linux, maybe even remove DRI support out st/egl if you must, but please don't go out of your way to break EGL on non-linux platforms. Jose From: mesa-dev on behalf of Emil Velikov Sent: 05 November 2014 00:46 To: Marek Olšák; mesa-dev@lists.freedesktop.org Cc: emil.l.veli...@gmail.com Subject: Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds 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. > > 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. > > Please comment. > 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 ? Cheers, Emil > Thanks, > > Marek > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-u
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
Marek Olšák writes: > 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: I'd love to see VG get nuked at the same time, but still: Reviewed-by: Eric Anholt pgpvPTYd4WPzF.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
On Wed, Nov 5, 2014 at 2:43 AM, Marek Olšák wrote: > On Wed, Nov 5, 2014 at 9:02 AM, Michel Dänzer wrote: >> On 05.11.2014 07: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. >> >> >> No argument there. >> >> >>> - OpenVG - It has never taken off. If people want this on Linux, it should >>> use egl_dri2 and st/dri, like OpenGL does. >> >> >> The problem is doing so would probably be a lot of work, so this creates a >> huge barrier for somebody who wants to play with OpenVG. >> >> How about keeping egl_gallium but only using it if EGL_DRIVER=egl_gallium is >> specified explicitly? (I assume automatically using egl_gallium for OpenVG >> isn't possible due to the way EGL works) > > Another alternative is to use a library which implements OpenVG on top > of OpenGL. For example: > - http://sourceforge.net/projects/shivavg/ > - https://github.com/micahpearlman/MonkVG For anybody who just wants to play with OpenVG this should be sufficient and, I expect, as useful and the gallium state tracker. If OpenVG suddenly takes off, we can revisit doing a more native driver for it. Marek, thanks for picking this up, I fully support getting rid of this, Acked-by: Kristian Høgsberg ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
On Wed, Nov 5, 2014 at 12:02 AM, Michel Dänzer wrote: > On 05.11.2014 07:42, Marek Olšák wrote: >> - OpenVG - It has never taken off. If people want this on Linux, it should >> use egl_dri2 and st/dri, like OpenGL does. > > > The problem is doing so would probably be a lot of work, so this creates a > huge barrier for somebody who wants to play with OpenVG. Are there such people? I don't see any meaningful work on vega since 2011. I don't see any work on Cairo's OpenVG backend since it was added in 2009 either. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
On Wed, Nov 5, 2014 at 9:02 AM, Michel Dänzer wrote: > On 05.11.2014 07: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. > > > No argument there. > > >> - OpenVG - It has never taken off. If people want this on Linux, it should >> use egl_dri2 and st/dri, like OpenGL does. > > > The problem is doing so would probably be a lot of work, so this creates a > huge barrier for somebody who wants to play with OpenVG. > > How about keeping egl_gallium but only using it if EGL_DRIVER=egl_gallium is > specified explicitly? (I assume automatically using egl_gallium for OpenVG > isn't possible due to the way EGL works) Another alternative is to use a library which implements OpenVG on top of OpenGL. For example: - http://sourceforge.net/projects/shivavg/ - https://github.com/micahpearlman/MonkVG Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
On Tue, 4 Nov 2014 23:42:43 +0100 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 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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
On 05.11.2014 07: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. No argument there. - OpenVG - It has never taken off. If people want this on Linux, it should use egl_dri2 and st/dri, like OpenGL does. The problem is doing so would probably be a lot of work, so this creates a huge barrier for somebody who wants to play with OpenVG. How about keeping egl_gallium but only using it if EGL_DRIVER=egl_gallium is specified explicitly? (I assume automatically using egl_gallium for OpenVG isn't possible due to the way EGL works) -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
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. > > 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. > > Please comment. > 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 ? Cheers, Emil > Thanks, > > Marek > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
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. 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. Please comment. Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
