[Mesa-dev] glGetString(GL_EXTENSIONS) omits mapbuffer extension
Roland Scheidegger
sroland at vmware.com
Mon Feb 27 07:19:27 PST 2012
Indeed, but that's not what the OP was claiming (he says it's not in the
extension string but works regardless, hence it probably should be in
the extension string).
As for why it's not there some quick look at extensions.c shows that it
is indeed supported (the functionality is pretty much part of ARB_vbo
after all). The only 2 OES extensions showing up are incidentally the
only 2 which are also available in a GL context. So this looks to be
some multi-API issue but I've no clue about that.
Roland
Am 25.02.2012 08:24, schrieb Ian Romanick:
> You can call GetProcAddress on ANYTHING and it won't return NULL. It will even return a pointer for glHamSandwich. You must check the extension string.
>
> On Feb 24, 2012, at 6:13 PM, Simon Que <sque at chromium.org> wrote:
>
>> Previously posted at mesa-users.
>>
>> TL;DR: GL_EXTENSIONS string does not contain "GL_OES_mapbuffer", but
>> the mapbuffer extension functions are still available through
>> eglGetProcAddress().
>>
>> I am using Mesa GLESv2 with Linaro's glmark2 benchmark. The benchmark
>> uses the functions "glMapBufferOES" and "glUnmapBufferOES" from the
>> "GL_OES_mapbuffer" extension, as seen in this function:
>>
>> http://git.linaro.org/gitweb?p=people/afrantzis/glmark2.git;a=blob;f=src/canvas-x11-egl.cpp;h=f69e6f40a32832c5cb12eafc94afc8d5d320887e;hb=HEAD#l256
>>
>> What this function does:
>> 1. Call glGetString(GL_EXTENSIONS), to get a string containing all the
>> extensions.
>> 2. Checks for "GL_OES_mapbuffer" in the extension list string from Step #1.
>> 3. If "GL_OES_mapbuffer" is found in Step #2, it proceeds to get the
>> functions gl[Map|UnMap]BufferOES.
>> 4. If it is not found, the function takes no action, and the benchmark
>> later fails because it was not given the map/unmap functions.
>>
>> However, I was able to get the map/unmap functions by bypassing the
>> check in Step #2 and calling eglGetProcAddress() regardless of whether
>> the string contained the mapbuffer extension. And then the benchmark
>> runs successfully, meaning that the mapbuffer extension actually does
>> exist, it is just not being exported in by glGetString(GL_EXTENSIONS).
>>
>> For reference, I am building Mesa with the following configuration:
>> ./configure --prefix=/usr --build=x86_64-pc-linux-gnu
>> --host=i686-pc-linux-gnu --mandir=/usr/share/man
>> --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
>> --localstatedir=/var/lib --disable-option-checking --with-driver=dri
>> --disable-glut --without-demos --enable-xcb --enable-egl
>> --enable-gles1 --enable-gles2 --enable-shared-glapi --enable-gallium
>> --disable-debug --enable-glx-tls --disable-glw --disable-motif
>> --enable-asm --with-dri-drivers=,i915,i965
>> --with-gallium-drivers=,swrast,i915 --with-egl-platforms=drm
>>
>> The only GL_OES extensions contained in the GL_EXTENSIONS string are:
>> GL_OES_read_format
>> GL_OES_EGL_image
>>
>> Thanks,
>> Simon
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list