[Mesa-dev] Naming conventions, DSA, and meta
t_arceri at yahoo.com.au
Mon Feb 2 21:12:37 PST 2015
On Mon, 2015-02-02 at 13:22 -0800, Eric Anholt wrote:
> Thomas Helland <thomashelland90 at gmail.com> writes:
> > 2015-02-02 19:18 GMT+01:00 Jason Ekstrand <jason at jlekstrand.net>:
> >> 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
> > Kind of off-topic, but since you're mentioning overhead of hash tables:
> > I've been doing some work on util/hash_table that is yet to be sent to the list.
> > Thought I could share my experience if someone happens to be
> > working on other improvements to the hash-tables.
> > TLDR of approach:
> > Power-of-two sized table instead of prime size.
> > -> We can replace the modulo with bitmasking to fit keys in the table.
> > -> Reduced overhead on insert, search, resize, etc.
> > -> FNV-1a has good avalanche properties -> collisions is a no-issue.
> There was also the idea of using a much cheaper hash. The hash cost
> itself is fairly large iirc. I'd love to see the two ideas tried out
> side by side (a cheap crc32 should be easy to test).
I spent a bit of time trying to tweak the hash table back in November
and posted my findings to the list . One thing I found was using
_mm_crc32_u8() to do the hash over the current FNV-1a implementation
gave a nice bump in hashing performance and didn't see any noticeable
change in collisions in my testing.
The real problem I had was finding something cpu limited to test with.
More information about the mesa-dev