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 _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
