<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi all,<br></div>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.<br><br></div>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:<br><br> 1) The entrypoint itself (currently _mesa_EntryPoint)<br> 2) the internal entrypoint (Laura chose _mesa_entry_point)<br> 3) the software fallback for the DD table entry (Laura chose _mesa_TableEntry_sw)<br><br></div>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.<br><br></div>Why the internal entrypoints?<br><br></div>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<br><br></div>_mesa_ActiveTexture(0)<br></div>_mesa_BindTexture(texObj->Target, texObj->Name);<br><br></div>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<br><br></div>_mesa_bind_texture_unit(cts, texObj, 0);<br><br></div>and accomplish the same thing without the overhead.  Also, in meta, the standard way of getting a texture is to do<br><br></div>_mesa_GenTextures(1, &name);<br></div>texObj = _mesa_lookup_texture(ctx, name);<br><br></div>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.)<br><br></div>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.<br><br></div>Ok, there's my justification for the way it's being refactored.  Now to arguing about names!<br></div>--Jason Ekstrand<br></div>