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<k...@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.vers...@linux.intel.com
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
