On 20.03.2017 14:33, Markus Wick wrote:
Am 2017-03-20 14:21, schrieb Nicolai Hähnle:
On 17.03.2017 18:59, gregory hainaut wrote:
If the application is badly/strangely coded, glthread will make it
worst.
The solution ought to be either fix the app or don't use glthread.
It would be nice if glthread could handle this properly, but I don't
currently see how.
The dispatcher thread needs a map of all valid buffer objects. So we
need to update such a map on all glGenBuffers/glDeleteBuffers calls. So
the overhead will be the map lookup on all affected glBindBuffer calls.
You're right. Ridiculous details of the OpenGL spec make this
interesting, actually, because Section 6.1 (Creating and Binding Buffer
Objects) of the OpenGL 4.5 (Compability Profile) spec says:
"A buffer object is created by binding an unused name to a buffer
target. The binding is effected by calling
void BindBuffer( enum target, uint buffer );
target must be one of the targets listed in table 6.1. If the buffer
object named buffer has not been previously bound, or has been deleted
since the last binding, the GL creates a new state vector, initialized
with a zero-sized memory buffer and comprising all the state and with
the same initial values listed in table 6.2."
But this language is different from that for core profiles, where a call
to glGenBuffers is required. So in this case, the compatibility profile
spec is actually better for performance :/
Cheers,
Nicolai
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
