[Mesa-dev] [PATCH 00/23] ARB_direct_state_access buffer objects (v2)

Martin Peres martin.peres at linux.intel.com
Mon Feb 16 01:18:05 PST 2015

On 12/02/15 22:12, Ilia Mirkin wrote:
> On Thu, Feb 12, 2015 at 3:09 PM, Martin Peres <martin.peres at free.fr> wrote:
>> On 12/02/15 04:05, Laura Ekstrand wrote:
>>> This includes a v2 of all of the buffer object code plus a v2 of the
>>> related
>>> TextureBufferRange entry point.
>>> Note that some implementations have been merged together (MapBuffer and
>>> MapBufferRange, for instance) because it didn't seem to make sense to keep
>>> two
>>> separate and nearly identical versions of the same code.
>>> As a reminder:
>>> Most of the implementation work involved abstracting the internals of the
>>> traditional GL functions and writing the DSA functions on top of these
>>> abstractions.  For instance, to implement GenerateTextureMipmap, most of
>>> the
>>> functionality of GenerateMipmap was moved to a function:
>>> void
>>> _mesa_generate_texture_mipmap(struct gl_context *ctx,
>>>                                 struct gl_texture_object *texObj,
>>>                                 GLenum target, bool dsa).
>>> GenerateMipmap and GenerateTextureMipmap
>>> were then implemented on top of this function as thin layers that get the
>>> context and the relevant texture object.
>> Someone commented on my code, stating that internal functions should not
>> have _mesa_ in their name and I think it makes sense. Do you have an
>> argument against that?
> I believe that someone was me, and that's not what I said. I said that
> *static* functions (i.e. functions internal to a .c file) shouldn't
> have a _mesa prefix. Ones that are exposed in .h files *should* have a
> _mesa prefix.
Fair-enough, I misinterpreted the message. Sorry for the noise.

More information about the mesa-dev mailing list