[Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2

[Ian Romanick]

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