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

[Roland Scheidegger]

Am 27.02.2012 18:46, schrieb 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.

I guess that's difficult to avoid with this being functionality which is
considered by mesa to be always available, and the oes extension using
all the same entry points (and as you said, it probably should be there
in a gles context for all drivers anyway).
And there's indeed a trivial aspect of it which appears broken, since
OES_mapbuffer says only WRITE_ONLY_OES is permitted. There's nothing in
the code which would prevent someone from using read/readwrite. (Though
while the spec says the parameter must be WRITE_ONLY_OES it does not
actually explicitly say a error must be generated otherwise but I would
guess that's sort of implicit.) That's quite pedantic however, and
there's probably quite a bit more of similar issues.

Roland