<div dir="ltr">Yes, Ilia's right.  The _mesa_buffer_data backend is exposed to the rest of the driver (for use in the near future in Meta), so it has "_meta".  In this v2, I discovered that some of the software fallbacks in bufferobj.c were static and named "_mesa" (not my doing).  I changed them in the v2 to remove the "_mesa."<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 12, 2015 at 12:12 PM, Ilia Mirkin <span dir="ltr"><<a href="mailto:imirkin@alum.mit.edu" target="_blank">imirkin@alum.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Feb 12, 2015 at 3:09 PM, Martin Peres <<a href="mailto:martin.peres@free.fr">martin.peres@free.fr</a>> wrote:<br>
> On 12/02/15 04:05, Laura Ekstrand wrote:<br>
>><br>
>> This includes a v2 of all of the buffer object code plus a v2 of the<br>
>> related<br>
>> TextureBufferRange entry point.<br>
>><br>
>> Note that some implementations have been merged together (MapBuffer and<br>
>> MapBufferRange, for instance) because it didn't seem to make sense to keep<br>
>> two<br>
>> separate and nearly identical versions of the same code.<br>
>><br>
>> As a reminder:<br>
>><br>
>> Most of the implementation work involved abstracting the internals of the<br>
>> traditional GL functions and writing the DSA functions on top of these<br>
>> abstractions.  For instance, to implement GenerateTextureMipmap, most of<br>
>> the<br>
>> functionality of GenerateMipmap was moved to a function:<br>
>> void<br>
>> _mesa_generate_texture_mipmap(struct gl_context *ctx,<br>
>>                                struct gl_texture_object *texObj,<br>
>>                                GLenum target, bool dsa).<br>
>> GenerateMipmap and GenerateTextureMipmap<br>
>> were then implemented on top of this function as thin layers that get the<br>
>> context and the relevant texture object.<br>
><br>
><br>
> Someone commented on my code, stating that internal functions should not<br>
> have _mesa_ in their name and I think it makes sense. Do you have an<br>
> argument against that?<br>
<br>
</div></div>I believe that someone was me, and that's not what I said. I said that<br>
*static* functions (i.e. functions internal to a .c file) shouldn't<br>
have a _mesa prefix. Ones that are exposed in .h files *should* have a<br>
_mesa prefix.<br>
<span class="HOEnZb"><font color="#888888"><br>
  -ilia<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</div></div></blockquote></div><br></div>