[Mesa-dev] [PATCH 1/7] mesa: implement glBindBuffersBase() and gl BindBuffersRange()

Brian Paul brianp at vmware.com
Tue Jan 7 07:23:33 PST 2014


On 01/07/2014 12:49 AM, Fredrik Höglund wrote:
> Maxence, while I think it's great that you're interested in working
> on this extension, I'm afraid I have another implementation in
> a branch in my mesa tree:
>
> https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/~fredrik/mesa/log/?h%3Darb-multi-bind&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=Qnaa0wxMyN0kizD7ysRrgyEbk4PXjC2dP%2BLpd%2FgAmuk%3D%0A&s=8fa229ff9512e319f49a8dede5aa158170e34178a81f3aff3e3d4164c084d574
>
> I've looked at your patches, and noticed you've implemented the
> functions by calling the _mesa_Bind*() functions in a loop.  I know
> that the specification uses examples that look very much like this
> to illustrate the intended effect of calling each function.  But when
> actually implemented in this this way you don't get the performance
> benefit you would get by writing a specialized implementation of
> each function.
>
> For example you can avoid locking the mutex that protects the hash
> table more than once when you look up the pointers to the objects.
> There is also some state validation that doesn't need to be repeated
> for each object.
>
> Another downside is that when an error occurs, the _mesa_Bind*()
> functions will report the wrong entry point in the error message.
> The quality of those messages is important now that we support
> KHR_debug, because they are reported to the client.
>
> While your implementation is simpler than mine, I think my approach
> is better in the long term. But I think others should chime in on this.

I think your series looks pretty good, Fredrik.  I don't recall you 
posting the patches for review yet.  When you do I'll have a few small 
comments.

Will you be writing some piglit tests too?

-Brian




More information about the mesa-dev mailing list