summaryrefslogtreecommitdiffstats
path: root/src/mesa/vbo/descrip.mms
diff options
context:
space:
mode:
authorChad Versace <[email protected]>2012-05-03 16:02:50 -0700
committerChad Versace <[email protected]>2012-05-07 08:38:12 -0700
commit1c0f5d8324c4db2720247989ddc4a45315b55a85 (patch)
tree7f120c41effca99f9b49880ddf2cbfaf9b337ce9 /src/mesa/vbo/descrip.mms
parent64c510bb72c7b81eb1fd96df47bdf62817a09fa7 (diff)
intel: Disable ARB_framebuffer_object in ES contexts
This patch removes ARB_framebuffer_object from the GLES1 and GLES2 extension lists in intel_extensions_es.c. Fixes a crash in the Android browser on Ice Cream Sandwich. The Android browser crashed because it did the following, which is legal in GLES2 but not in ARB_framebuffer_object. glGenFramebuffers(1, &fb); glBindFramebuffer(GL_FRAMEBUFFER, fb); // render render render... glDeleteFramebuffers(1, &fb); // go do other stuff... glBindFramebuffer(GL_FRAMEBUFFER, fb); // This bind unexpectedly failed, and the app panics. The semantics of glBindFramebuffer specified by ARB_framebuffer_object (a desktop GL extension) and GLES2 specs are incompatible. The ideal solution to fix this is to create separate API entry points for glBindFramebuffer, one for GL and the other for GLES2. But, until that work is complete, disabling ARB_framebuffer_object in GLES2 contexts safely fixes the problem. Likewise, the semantics of glBindFramebuffer in ARB_framebuffer_object and of glBindFramebufferOES in OES_framebuffer_object (a GLES1 extension) are incompatible. Even though the functions have different names, the semantic difference still results in a bug because both API calls are implemented by a single function, _mesa_BindFramebufferEXT, which handles the semantic difference incorrectly. Again, disabling ARB_framebuffer_object in GLES1 contexts safely fixes this problem. According to the ARB_framebuffer_object spec, the extension is an amalgamation of EXT_framebuffer_object EXT_framebuffer_blit EXT_packed_depth_stencil EXT_framebuffer_multisample By disabling this extension, however, no functionality is removed from GLES1 and GLES2 contexts because 1) the first three extensions are explicitly enabled in Intel's ES extension lists and 2) no functionality of the last extension is exposed in an ES context. Note: This is a candidate for the 8.0 branch. See-also: http://www.mail-archive.com/[email protected]/msg21006.html CC: Charles Johnson <[email protected]> CC: Sean Kelley <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Chad Versace <[email protected]>
Diffstat (limited to 'src/mesa/vbo/descrip.mms')
0 files changed, 0 insertions, 0 deletions