Re: [Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
On Thu, May 3, 2012 at 3:32 AM, Chad Versace chad.vers...@linux.intel.com wrote: (FYI, if I understand the gallium code, the only drivers that currently enable both are Intel, swrast, and OSMesa). Gallium also enables both if packed depth-stencil textures are supported (which is the case with most, if not all, drivers). Otherwise, it only enables the EXT variant. 2. Create separate entry points: - _mesa_BindFramebufferEXT, which implements - glBindFramebufferEXT - glBindFramebufferOES - glBindFramebuffer in GLES2 - _mesa_BindFramebufferARB, which implements - glBindFramebufferARB - glBindFramebuffer in GL 3.x Any opinions? (I slightly prefer 2). FWIW, 2 seems to be a good plan to me too. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
On 05/02/2012 06:32 PM, Chad Versace wrote: Mesa has problems in the way it implements glBindFramebuffer and glBindFramebufferEXT due to both being implemented by an overloaded _mesa_BindFramebufferEXT. This problem causes an Android app [1] to crash, and I want your opinion on how we should fix it. The problem is that in the five specs in the subject line, the specified behavior of glBindFramebuffer falls into two incompatible categories. Mesa implements the wrong behavior for OES_fbo, EXT_fbo, and GLES2 when ARB_fbo is internally enabled. [1] Pauli and Charles (CC'd) have more details about this crash, including an apitrace, if you're curious. Behavior in Category A: ARB_fbo and GL3.0 - The behavior in these specs can be summarized as: 1a. glBindFramebuffer may be called only on fb names produced by glGenFramebuffers. 2a. glBindFramebuffer may not be called on an fb name previously deleted with glDeleteFramebuffers. Below is the pertinent quote from the ARB_fbo spec. The language in the GL 3.0 spec is nearly identical. A framebuffer object is created by binding a name returned by GenFramebuffers (see below) to DRAW_FRAMEBUFFER or READ_FRAMEBUFFER. The binding is effected by calling void BindFramebuffer(enum target, uint framebuffer); [...] BindFramebuffer fails and an INVALID_OPERATION error is generated if framebuffer is not zero or a name returned from a previous call to GenFramebuffers, or if such a name has since been deleted with DeleteFramebuffers. Behavior in Category B: EXT/OES_fbo and GLES2 -- The behavior in these specs can be summarized as below. This behavior is incompatible with points 1a and 2a. 1b. glBindFramebuffer may be called on any unused fb name. 2b. glBindFramebuffers may be called on an fb name previously deleted with glDeleteFramebuffers because, according to these specs, deletion marks a name as unused. Below is the pertininent quote from the EXT_fbo spec. The language of the GLES 2 spec is nearly identical, but without the EXT suffix. The OES_fbo spec refers to the EXT_fbo spec. The namespace for framebuffer objects is the unsigned integers, with zero reserved by the GL to refer to the default framebuffer. A framebuffer object is created by binding an unused name to the target FRAMEBUFFER_EXT. The binding is effected by calling void BindFramebufferEXT(enum target, uint framebuffer); [...] Framebuffer objects are deleted by calling void DeleteFramebuffersEXT(sizei n, uint *framebuffers); framebuffers containsn names of framebuffer objects to be deleted. After a framebuffer object is deleted, [...], and its name is again unused. The Crashing App We have an Android app that does this: 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. So... the app is expecting this to create a fresh FBO? The call to glBindFramebuffer fails because, in GLES1 and GLES2 contexts, the Intel drivers internally enables both ARB_fbo and EXT_fbo. In _mesa_BindFramebufferEXT, the ARB_fbo behavior wins. Solutions for core Mesa --- As for fixing _mesa_BindFramebufferEXT, I have two ideas. 1. Enforce in _mesa_BindFramebufferEXT that no more than one of ARB_fbo and EXT_fbo is enabled, then clean up its validation logic. This is a big hammer, and, if done right, can eliminate any ambiguities in behavior. (FYI, if I understand the gallium code, the only drivers that currently enable both are Intel, swrast, and OSMesa). I'm not a fan of this. We only redact functionality that don't believe anyone uses. I'm fairly sure there are still apps that will use EXT_fbo. 2. Create separate entry points: - _mesa_BindFramebufferEXT, which implements - glBindFramebufferEXT - glBindFramebufferOES - glBindFramebuffer in GLES2 - _mesa_BindFramebufferARB, which implements - glBindFramebufferARB - glBindFramebuffer in GL 3.x This is my preference. I believe vertex array objects work like this. See src/mesa/main/arrayobj.c. Any opinions? (I slightly prefer 2). 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? ___ mesa-dev mailing list
Re: [Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
On Wed, 02 May 2012 18:32:01 -0700, Chad Versace chad.vers...@linux.intel.com
wrote:
Solutions for core Mesa
---
As for fixing _mesa_BindFramebufferEXT, I have two ideas.
1. Enforce in _mesa_BindFramebufferEXT that no more than one of ARB_fbo
and EXT_fbo is enabled, then clean up its validation logic. This is
a big hammer, and, if done right, can eliminate any ambiguities in
behavior.
(FYI, if I understand the gallium code, the only drivers that currently
enable both are Intel, swrast, and OSMesa).
2. Create separate entry points:
- _mesa_BindFramebufferEXT, which implements
- glBindFramebufferEXT
- glBindFramebufferOES
- glBindFramebuffer in GLES2
- _mesa_BindFramebufferARB, which implements
- glBindFramebufferARB
- glBindFramebuffer in GL 3.x
3. Just change this hunk of _msea_BindFramebufferEXT:
else if (!newDrawFb ctx-Extensions.ARB_framebuffer_object) {
/* All FBO IDs must be Gen'd */
_mesa_error(ctx, GL_INVALID_OPERATION, glBindFramebuffer(buffer));
return;
}
to just not throw the error if EXT_fbo or if the API is ES2?
pgpwcLkijtE6P.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2012 10:33 AM, Eric Anholt wrote:
On Wed, 02 May 2012 18:32:01 -0700, Chad Versace
chad.vers...@linux.intel.com wrote:
Solutions for core Mesa
---
As for fixing _mesa_BindFramebufferEXT, I have two ideas.
1. Enforce in _mesa_BindFramebufferEXT that no more than one of ARB_fbo
and EXT_fbo is enabled, then clean up its validation logic. This is
a big hammer, and, if done right, can eliminate any ambiguities in
behavior.
(FYI, if I understand the gallium code, the only drivers that currently
enable both are Intel, swrast, and OSMesa).
2. Create separate entry points:
- _mesa_BindFramebufferEXT, which implements
- glBindFramebufferEXT
- glBindFramebufferOES
- glBindFramebuffer in GLES2
- _mesa_BindFramebufferARB, which implements
- glBindFramebufferARB
- glBindFramebuffer in GL 3.x
3. Just change this hunk of _msea_BindFramebufferEXT:
else if (!newDrawFb ctx-Extensions.ARB_framebuffer_object) {
/* All FBO IDs must be Gen'd */
_mesa_error(ctx, GL_INVALID_OPERATION, glBindFramebuffer(buffer));
return;
}
to just not throw the error if EXT_fbo or if the API is ES2?
I don't believe 3 will work.
Suppose we are in a GL3.x context with EXT_fbo advertised.
Once the execution path has entered _mesa_BindFramebufferEXT, it is not
possible to know
if the client called glBindFramebuffer (which has ARB_fbo semantics) or called
glBindFramebufferEXT, yet the two functions have different behavior. As far as
I can tell,
the only way to give the functions different behavior is create separate API
entry points.
-
Chad Versace
chad.vers...@linux.intel.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJPos58AAoJEAIvNt057x8ier0P/363zaXqqMaF5QN1qJXnBteg
Sz45Kn4yseubOHQ+Hrsx4PVoRI6UtpR1wlVnD9/vSiVU9u/uA8jBLDMd//oZ73xA
hVXy+UfiFv/d/yJqXMIR1gvli0mtThOdpZD8LVN7whAVYILyZQdBQE66OBd5RNY4
MEUVYpCbIuLUN6k0Zq7KP8V0j8yk5OmbxBKT71finxYUsq0HNjNQ5UaCZLVtrL06
wiz5Y07P3G8QOrbLLXSVNvBglj58llEkF6BjrKb13/tRnKs40UEnN5tTZ8A1T2F9
EI0yZga8B/ZLciox7F38ByW/5sJZPSCqs7A18dab/Lzj8W7fBeoE1Grky+xhzbnu
M9OAwf0yIQbS3MdH8y15h35M1wyFkAUq3NdPm1D5PfYX9BlHZxqpOkWG/P1/T1Hf
5N+Qhl8Tc9ghqPcOMM2453tWF7AoK9Qs5BdXTHRB3Bi1q/NhCVzEFsuOYTbtpPOI
Zlu2OnpidKMsUR+X+zUjXq5nEh9T0j7Zubvr0YJde/Nok375MLLKAIhhiFy3RTIX
DT4WYsItFo3rAOgcTvKUpFqOQZEjzwyi2bo2+438oZXz7I3tbP8CJH17KrtvJvsr
70M3ix2j+TJC8yKyR1eAiWLFluf3ZNgdqD3wevQv6wHmuZKJ5PC9nXvnm0WpsmzL
AgqLaYiIJkHsKVo2Syyp
=V13D
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
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 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
Re: [Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
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øgsbergk...@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
Re: [Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
On 05/02/2012 06:32 PM, Chad Versace wrote: Mesa has problems in the way it implements glBindFramebuffer and glBindFramebufferEXT due to both being implemented by an overloaded _mesa_BindFramebufferEXT. This problem causes an Android app [1] to crash, and I want your opinion on how we should fix it. The problem is that in the five specs in the subject line, the specified behavior of glBindFramebuffer falls into two incompatible categories. Mesa implements the wrong behavior for OES_fbo, EXT_fbo, and GLES2 when ARB_fbo is internally enabled. [snip] Solutions for core Mesa --- As for fixing _mesa_BindFramebufferEXT, I have two ideas. [snip] 2. Create separate entry points: - _mesa_BindFramebufferEXT, which implements - glBindFramebufferEXT - glBindFramebufferOES - glBindFramebuffer in GLES2 - _mesa_BindFramebufferARB, which implements - glBindFramebufferARB - glBindFramebuffer in GL 3.x 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. Thanks for everyone's feedback. Based on the discussion, I plan to 1. Submit a patch that disables ARB_fbo in Intel ES contexts. 2. Write some Piglit tests to probe the expected behavior in different extensions and APIs. 3. Start working to separate the API entry points. Chad Versace chad.vers...@linux.intel.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
Mesa has problems in the way it implements glBindFramebuffer and glBindFramebufferEXT due to both being implemented by an overloaded _mesa_BindFramebufferEXT. This problem causes an Android app [1] to crash, and I want your opinion on how we should fix it. The problem is that in the five specs in the subject line, the specified behavior of glBindFramebuffer falls into two incompatible categories. Mesa implements the wrong behavior for OES_fbo, EXT_fbo, and GLES2 when ARB_fbo is internally enabled. [1] Pauli and Charles (CC'd) have more details about this crash, including an apitrace, if you're curious. Behavior in Category A: ARB_fbo and GL3.0 - The behavior in these specs can be summarized as: 1a. glBindFramebuffer may be called only on fb names produced by glGenFramebuffers. 2a. glBindFramebuffer may not be called on an fb name previously deleted with glDeleteFramebuffers. Below is the pertinent quote from the ARB_fbo spec. The language in the GL 3.0 spec is nearly identical. A framebuffer object is created by binding a name returned by GenFramebuffers (see below) to DRAW_FRAMEBUFFER or READ_FRAMEBUFFER. The binding is effected by calling void BindFramebuffer(enum target, uint framebuffer); [...] BindFramebuffer fails and an INVALID_OPERATION error is generated if framebuffer is not zero or a name returned from a previous call to GenFramebuffers, or if such a name has since been deleted with DeleteFramebuffers. Behavior in Category B: EXT/OES_fbo and GLES2 -- The behavior in these specs can be summarized as below. This behavior is incompatible with points 1a and 2a. 1b. glBindFramebuffer may be called on any unused fb name. 2b. glBindFramebuffers may be called on an fb name previously deleted with glDeleteFramebuffers because, according to these specs, deletion marks a name as unused. Below is the pertininent quote from the EXT_fbo spec. The language of the GLES 2 spec is nearly identical, but without the EXT suffix. The OES_fbo spec refers to the EXT_fbo spec. The namespace for framebuffer objects is the unsigned integers, with zero reserved by the GL to refer to the default framebuffer. A framebuffer object is created by binding an unused name to the target FRAMEBUFFER_EXT. The binding is effected by calling void BindFramebufferEXT(enum target, uint framebuffer); [...] Framebuffer objects are deleted by calling void DeleteFramebuffersEXT(sizei n, uint *framebuffers); framebuffers contains n names of framebuffer objects to be deleted. After a framebuffer object is deleted, [...], and its name is again unused. The Crashing App We have an Android app that does this: 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 call to glBindFramebuffer fails because, in GLES1 and GLES2 contexts, the Intel drivers internally enables both ARB_fbo and EXT_fbo. In _mesa_BindFramebufferEXT, the ARB_fbo behavior wins. Solutions for core Mesa --- As for fixing _mesa_BindFramebufferEXT, I have two ideas. 1. Enforce in _mesa_BindFramebufferEXT that no more than one of ARB_fbo and EXT_fbo is enabled, then clean up its validation logic. This is a big hammer, and, if done right, can eliminate any ambiguities in behavior. (FYI, if I understand the gallium code, the only drivers that currently enable both are Intel, swrast, and OSMesa). 2. Create separate entry points: - _mesa_BindFramebufferEXT, which implements - glBindFramebufferEXT - glBindFramebufferOES - glBindFramebuffer in GLES2 - _mesa_BindFramebufferARB, which implements - glBindFramebufferARB - glBindFramebuffer in GL 3.x Any opinions? (I slightly prefer 2). 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? - Chad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
