Hello, Sorry I was in vacation. I will update my patch with a hash map to trace buffer creation/destruction.
Cheers, Gregory On 3/20/17, Nicolai Hähnle <nhaeh...@gmail.com> wrote: > 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
