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

Laura Ekstrand laura at jlekstrand.net
Thu Feb 12 12:42:06 PST 2015


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."

On Thu, Feb 12, 2015 at 12:12 PM, Ilia Mirkin <imirkin at alum.mit.edu> 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.
>
>   -ilia
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150212/9813a61b/attachment.html>


More information about the mesa-dev mailing list