diff options
author | Tomasz Lis <[email protected]> | 2013-07-16 20:57:26 +0200 |
---|---|---|
committer | Ian Romanick <[email protected]> | 2013-07-18 17:42:46 -0700 |
commit | 9f07ca11c1797ac12de1e1c6aef13cf58824b5f5 (patch) | |
tree | c2da04cb8013e3c2e0180b1970ba4dd1e76500be /src/mesa/main/fbobject.c | |
parent | adfd0123c8e70ff9bf1d8044a7e38029cfdf300f (diff) |
mesa: Dispatch ARB_framebuffer_object and EXT_framebuffer_object differently9.2-branchpoint
Almost all of the functions between the ARB and the EXT share the same
GLX protocol because the functionality is, essentially, identical.
However, there are some differences between the extensions:
- In the ARB extension, names must come from glGenBuffers.
- In the ARB extension, framebuffer objects are not shared (but they are
in the EXT).
For these reasons, glBindFramebuffer and glBindRenderbuffer have
different GLX protocol opcodes than their EXT counterparts. Currently
these functions alias each other in the dispatch table. This makes it
impossible to be truly spec conformant.
This patch enables fixing the conformance issue by splitting
glBindFramebuffer / glBindFramebufferEXT and glBindRenderbuffer /
glBindRenderbufferEXT into separate dispatch table entries.
Patches will be available shortly to:
- Fix the conformance issue.
- Stop advertising the EXT in OpenGL 3.1 (or core profiles).
HOWEVER, this does represent a compatibility break between the loader
(libGL or the Xserver GLX module) and the driver. Mesa drivers compiled
without this change will request a single dispatch table entry for
glBindFramebuffer and glBindFramebufferEXT. Since the updated loader
has different entries for each, the request will fail, and the driver
will die in a fire.
Drivers built with the change should continue to load fine on loaders
without the change. In this case, the driver will separately ask for
entries for glBindFramebuffer and glBindFramebufferEXT, and the loader
will tell it the same location. Since the loader in the server's GLX
module is not (yet) updated, this should not be a problem. We also do
not advertise the ARB extension from the server, so, again, this should
not be a problem for the server.
HOWEVER, this means that DRI1 drivers (remember mga_dri.so?) will no
longer load with libGL build hereafter. That means this patch will need
to be back ported to the 8.0 branch.
v2 (idr): Added missing GLX protocol opcodes for the EXT functions and
corrected the opcodes for the ARB functions. Updated GLX indirect_api
unit test and dispatch sanity unit test.
Signed-off-by: Tomasz Lis <[email protected]>
Signed-off-by: Bartosz Zawistowski <[email protected]>
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Ian Romanick <[email protected]> [v1]
Diffstat (limited to 'src/mesa/main/fbobject.c')
-rw-r--r-- | src/mesa/main/fbobject.c | 14 |
1 files changed, 14 insertions, 0 deletions
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c index f59fdb12d08..a29f1ab13c0 100644 --- a/src/mesa/main/fbobject.c +++ b/src/mesa/main/fbobject.c @@ -1155,6 +1155,13 @@ _mesa_BindRenderbuffer(GLenum target, GLuint renderbuffer) } +void GLAPIENTRY +_mesa_BindRenderbufferEXT(GLenum target, GLuint renderbuffer) +{ + _mesa_BindRenderbuffer(target, renderbuffer); +} + + /** * If the given renderbuffer is anywhere attached to the framebuffer, detach * the renderbuffer. @@ -2025,6 +2032,13 @@ _mesa_BindFramebuffer(GLenum target, GLuint framebuffer) } } +void GLAPIENTRY +_mesa_BindFramebufferEXT(GLenum target, GLuint framebuffer) +{ + _mesa_BindFramebuffer(target, framebuffer); +} + + void GLAPIENTRY _mesa_DeleteFramebuffers(GLsizei n, const GLuint *framebuffers) |