| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
These changes are necessary for programs whose set of active attributes is not fixed at compile time by a template parameter pack, but rather varies based on the generated shader text at runtime. In such cases, the attribute location of a given named attribute may vary between instances of the same Program.
Previously, attribute bindings were implicitly associated with a location based on template parameter order, and -1 was used to indicate an inactive attribute. This left us unable to disable the appropriate attribute when it went from active to inactive. Now, the state tracker for bindings explicitly associates locations and state, and an empty optional is used to indicate an inactive attribute.
In addition, a gl::VertexArray class is now exposed, allowing more flexibility in the relationship between Programs, Segments, and attribute bindings. In this commit, that relationship does not change, but the subsequent commit adjusts it to match gl-js, reduce rebinds, and work around buggy VAO implementations.
VertexArray uses a pimpl idiom in order to support implementations that lack the VAO extension. In that case, all VertexArrays share global binding state, reflecting the platform reality in the absence of VAOs, while still providing a uniform API.
|
| | |
|
| | |
|
| |
|
|
|
| |
limits (#9373)
Introducing two new attributes to enable property functions for line-width (#9250) pushed the attribute count over GL_MAX_VERTEX_ATTRIBS on some devices. Now we selectively bind only attributes that are used, making it unlikely to surpass GL_MAX_VERTEX_ATTRIBS.
|
| |
|
|
| |
Rather than binding constant attributes that will never be used, just disable the attribute.
|
| |
|
|
|
|
|
|
|
| |
We have an "oldBinding" value that we use for checking whether the vertex attribute was already
bound to the current VAO, but we never set the state. Additionally, we're also checking whether
the previous state was already any binding (optional is set), and don't re-enable the vertex
attribute array. Additionally, we now only disable the vertex attribute array when the previous
state was in fact an array attribute. We still don't deduplicate constant glVertexAttrib* calls,
but that's a little trickier.
|
| | |
|
| |
|
|
|
|
|
|
| |
Some devices supported by Mapbox GL provide only 8 vertex attributes; this change packs existing attributes to get us just under that limit.
For properties using a composite function, pack the min and max values into a single attribute with two logical components instead of using two separate attributes and buffers. Special logic is included for color attributes, whose integer components must be packed into the available bits of floating-point attributes. (We don't have access to ivec types in GL ES 2.0.)
For source functions, continue to bind just a one-component attribute even though the GLSL type is vec2 (or vec4 for colors). The type-checking done by gl::Attribute is relaxed slightly to accommodate this.
|
| | |
|
| |
|
|
|
|
|
| |
Two reasons to prefer explicit sequential location assignment, rather than relying on the GLSL linker to assign locations:
* For data-driven properties, we want to have the option to use glDisableVertexAttribArray plus glVertexAttrib*. In order to use glDisableVertexAttribArray, we must avoid using attribute location 0, which cannot be disabled.
* We want to use the same VAO in cases where, say, a fill layer might be rendered with FillProgram at first, and then FillPatternProgram later. VAOs do not store the program binding, only the attribute bindings, so as long as the two programs have the same attributes and attribute locations, only a single VAO (per segment) is needed.
|
| | |
|
| |
|
