[Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
Ian Romanick
idr at freedesktop.org
Thu May 3 13:29:01 PDT 2012
On 05/03/2012 11:49 AM, Chad Versace wrote:
> On 05/03/2012 08:42 AM, Ian Romanick wrote:
>> On 05/02/2012 06:32 PM, Chad Versace wrote:
>
>>> Quick Solution for the Intel drivers
>>> ------------------------------------
>>>
>>> A quick solution may be as simple as removing ARB_fbo from the Intel drivers'
>>> GLES1/2 extension lists.
>>>
>>> Do you see any problem in doing this?
>>>
>>> Charles, you have experimented with disabling ARB_fbo from GLES1/2 contexts.
>>> Did you observe any negative consequences?
>
> Ian,
>
> Do you think its safe for us to remove ARB_fbo from the GLES1 and GLES2
> extension lists in intel_extensions_es.c? The lists have included
I'm ambivalent. Ultimately, I'd like to see this partitioning go away.
The driver should enable the features that it supports, and core Mesa
should advertise the appropriate functionality. Having two sets of
extension lists is annoying and error prone.
> ARB_fbo since day one, added at
>
> commit a5107b0a5cb1ac9f112aa498f57c13580bd56cb3
> Author: Kristian Høgsberg<krh at bitplanet.net>
> Date: Tue Apr 27 14:57:51 2010 -0400
>
> intel: Only register ES2 extensions for ES2 contexts
>
> I think it's safe because
>
> 1. ARB_fbo is not exposed in the extension string of ES contexts,
> so no ES app explicitly relies on that extension.
>
> 2. The ARB_fbo extension, according to the spec, is an amalgamation
> of
> EXT_framebuffer_object
> EXT_framebuffer_blit
> EXT_packed_depth_stencil
> EXT_framebuffer_multisample
> The first three are already enabled in intel_extensions_es.c,
> and functionality of the last, EXT_fb_multisample, isn't exposed
> in ES.
>
> ----
> Chad Versace
> chad.versace at linux.intel.com
More information about the mesa-dev
mailing list