1009965 - be explicit about whether we're quering for core GL symbols or extension GL symbols

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: do explicit extension/core queries

This comes up with some things like framebuffer_multisample -- it might be core, or it might be in an extension.

If it's core, like in ES 3, then we'll have a symbol without a suffix.  But it might not be (is not) legal to call that symbol on an ES2 context, even though it exists.  ANGLE enforces this.  So this patch makes it so that we check and see if a feature is core or not, and if it is, then we only query the undecorated symbols.

To be 100% correct we should only query for symbols for the specific extension that we found first, but I don't think that's needed.

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

Comment on attachment 8422117 [details] [diff] [review]
do explicit extension/core queries

Review of attachment 8422117 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/gl/GLContext.cpp
@@ +49,5 @@
>  namespace mozilla {
>  namespace gl {
>  
> +// from GLContextFeatures.cpp
> +bool IsFeaturePartOfProfileVersion(GLFeature feature, ContextProfile profile, unsigned int version);

It would be nice to have this prototype in a header.

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: Part 2: Handle ARB extensions properly

Ugh.  It turns out there are some ARB extensions that don't use symbols with ARB in the suffix; specifically, extensions that were created to match existing core GL functionality (or simultaneously released along with a new GL version, in order to provide the feature on downrev GL versions).  For these, the functions are defined to behave exactly like core, so there is no ARB suffix.

ARB_vertex_array_object is one of these.  The compounding issue is that Mesa/Gallium/llvmpipe seems to *never* return NULL from glXGetProcAddress(); instead it generates dummy dispatch table entries that are supposed to be filled in when a context is actually made current.  So we were querying for, for example, glGenVertexArraysARB which shouldn't exist, but getting a pointer back.

Some docs we found say that actually calling those functions should crash, but it definitely doesn't crash for us; they just seem to set a GL error and continue.  Likewise, it's always the same function pointer that's returned (no new entries were created).

This patch handles these ARB extensions and uses the core symbol tables for looking them up.

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0c408ede302a

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/rev/0c408ede302a