[Mesa-dev] glGetString(GL_EXTENSIONS) omits mapbuffer extension

[Ian Romanick]

On 02/27/2012 07:19 AM, Roland Scheidegger wrote:
> 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.

Right.  I was replying from my phone, so I couldn't really give the full 
answer. :)  The primary reason for some GLES2 extensions that are the 
same as desktop functionality not being enabled (at least on the Intel 
drivers) is that we don't have any GLES2-specific tests.  I'm 
increasingly reluctant to enable things that aren't specifically tested. 
  Almost every time we do, there's some trivial aspect of the 
functionality that's broken.

That it works without being advertised is, I would say, a bug.

> 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

Is this the GL_EXTENSIONS from a desktop GL context (e.g., via glxinfo) 
or from a GLES2 context (e.g., via es2_info in Mesa-demos)?  Desktop GL 
extensions are not supposed to be advertised in ES contexts, and ES 
extensions are not supposed to be advertised in desktop GL contexts.

On my Sandybridge laptop I get the following in a ES2 context:

EGL_VERSION = 1.4 (DRI2)
EGL_VENDOR = Mesa Project
EGL_EXTENSIONS = EGL_MESA_drm_image EGL_KHR_image_base 
EGL_KHR_image_pixmap EGL_KHR_image EGL_KHR_gl_renderbuffer_image 
EGL_KHR_surfaceless_gles1 EGL_KHR_surfaceless_gles2 
EGL_KHR_surfaceless_opengl EGL_NOK_swap_region 
EGL_NOK_texture_from_pixmap EGL_NV_post_sub_buffer
EGL_CLIENT_APIS = OpenGL OpenGL_ES OpenGL_ES2
GL_VERSION: OpenGL ES 2.0 Mesa 8.1-devel
GL_RENDERER: Mesa DRI Intel(R) Sandybridge Mobile
GL_EXTENSIONS:
     GL_EXT_blend_minmax, GL_EXT_multi_draw_arrays,
     GL_EXT_texture_filter_anisotropic, GL_EXT_texture_format_BGRA8888,
     GL_OES_depth24, GL_OES_element_index_uint, GL_OES_fbo_render_mipmap,
     GL_OES_mapbuffer, GL_OES_rgb8_rgba8, GL_OES_standard_derivatives,
     GL_OES_stencil8, GL_OES_texture_3D, GL_OES_texture_npot,
     GL_OES_EGL_image, GL_OES_depth_texture, GL_OES_packed_depth_stencil,
     GL_EXT_texture_type_2_10_10_10_REV, GL_NV_fbo_color_attachments,
     GL_NV_draw_buffers

And I've just noticed the GL_OES_mapbuffer is listed.

>>> Thanks,
>>> Simon
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev