[Mesa-dev] Naming conventions, DSA, and meta

Jason Ekstrand jason at jlekstrand.net
Mon Feb 2 10:18:25 PST 2015


Hi all,
I wanted to send out a quick message about naming conventions for mesa
entrypoints and dd table fallbacks.  There has been some confusion and
disagreement about this with some of the stuff Laura has been doing to
implement DSA.  Instead of side-track one of those patches for this
discussion, I thought it was worth its own e-mail.

When Laura started working on DSA, I suggested that, since we're
refactoring everything anyway, we refactor the guts of the entrypoint into
a DSA-style "internal entrypoint".  This internal entrypoint takes a
gl_context pointer, does less error checking, and actual mesa object
pointers instead of GLuint names.  I'll get to why in a minute here.
However, that leaves us needing a naming convention for three things:

 1) The entrypoint itself (currently _mesa_EntryPoint)
 2) the internal entrypoint (Laura chose _mesa_entry_point)
 3) the software fallback for the DD table entry (Laura chose
_mesa_TableEntry_sw)

I think we can all agree on not changing (1).  Previously we had something
of a convention of _mesa_entry_point for (3) but it wasn't perfectly
consistent.  Since we didn't have DSA, we didn't have anything for (2).
Personally, I'm OK with what Laura chose, but I understand that it's a
change of convention.  Another option, would be to do _mesa_main_TableEntry
or _mesa_main_table_entry for the standard DD fallback.  Or we can come up
with a different convention for the internal entry points.  I don't care
much.

Why the internal entrypoints?

The first reason is that we have to do the refactor anyway, and that seems
reasonable.  The more important reason is meta.  This is something that
Kristian, Ken and I have talked about a good bit lately.  I've done some
traces with meta lately and meta_begin/end show up a lot and what shows up
more is hash table lookups and, in particular, the mutex lock/unlock that's
involved.  Inside meta, we do all sorts of stupidity like

_mesa_ActiveTexture(0)
_mesa_BindTexture(texObj->Target, texObj->Name);

The entrypoint that's called here looks up the context again, re-does all
the error checking (even though we know it's not needed), takes in
texObj->Name and looks it up in the hash table to get texObj again, looks
up the texture unit and does the bind.  With the internal DSA entrypoint,
we can do

_mesa_bind_texture_unit(cts, texObj, 0);

and accomplish the same thing without the overhead.  Also, in meta, the
standard way of getting a texture is to do

_mesa_GenTextures(1, &name);
texObj = _mesa_lookup_texture(ctx, name);

This is insane!  There is no reason why we should be doing this sort of
nonsense when we're inside the driver.  I think that switching meta over to
using these internal entrypoints is going to cut down a lot on the
overhead.  Also, there are some meta functions that, with DSA-style
entrypoints, won't even need to save/restore at all because they don't
touch client state other than to create objects and set up a little stae.
(Admittedly, that's more of a DSA thing than an internaal entry point
thing.)

The other aspect, beyond performance, is that it will allow us to create
"nameless" objects that aren't present in the hash-table at all.
Scribbling over the client's namespace is a dangerous game and it's bitten
us in the past.  Doing everything with the pointers themselves instead of
GLuint names will allow us to eventually stop doing this.

Ok, there's my justification for the way it's being refactored.  Now to
arguing about names!
--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150202/ed8a4458/attachment.html>


More information about the mesa-dev mailing list