<p dir="ltr">I'm planning to release a v2 for buffer objects.  Can we get the naming scheme decided upon?  I suggest mesa buffer data fallback.</p>
<div class="gmail_quote">On Feb 3, 2015 10:30 AM, "Kristian Høgsberg" <<a href="mailto:krh@bitplanet.net">krh@bitplanet.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Feb 2, 2015 at 11:59 AM, Thomas Helland<br>
<<a href="mailto:thomashelland90@gmail.com">thomashelland90@gmail.com</a>> wrote:<br>
> 2015-02-02 19:18 GMT+01:00 Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>>:<br>
>> Hi all,<br>
>> I wanted to send out a quick message about naming conventions for mesa<br>
>> entrypoints and dd table fallbacks.  There has been some confusion and<br>
>> disagreement about this with some of the stuff Laura has been doing to<br>
>> implement DSA.  Instead of side-track one of those patches for this<br>
>> discussion, I thought it was worth its own e-mail.<br>
>><br>
>> When Laura started working on DSA, I suggested that, since we're refactoring<br>
>> everything anyway, we refactor the guts of the entrypoint into a DSA-style<br>
>> "internal entrypoint".  This internal entrypoint takes a gl_context pointer,<br>
>> does less error checking, and actual mesa object pointers instead of GLuint<br>
>> names.  I'll get to why in a minute here.  However, that leaves us needing a<br>
>> 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<br>
>> _mesa_TableEntry_sw)<br>
>><br>
>> I think we can all agree on not changing (1).  Previously we had something<br>
>> of a convention of _mesa_entry_point for (3) but it wasn't perfectly<br>
>> consistent.  Since we didn't have DSA, we didn't have anything for (2).<br>
>> Personally, I'm OK with what Laura chose, but I understand that it's a<br>
>> change of convention.  Another option, would be to do _mesa_main_TableEntry<br>
>> or _mesa_main_table_entry for the standard DD fallback.  Or we can come up<br>
>> with a different convention for the internal entry points.  I don't care<br>
>> much.<br>
>><br>
>> Why the internal entrypoints?<br>
>><br>
>> The first reason is that we have to do the refactor anyway, and that seems<br>
>> reasonable.  The more important reason is meta.  This is something that<br>
>> Kristian, Ken and I have talked about a good bit lately.  I've done some<br>
>> traces with meta lately and meta_begin/end show up a lot and what shows up<br>
>> more is hash table lookups and, in particular, the mutex lock/unlock that's<br>
>> involved.  Inside meta, we do all sorts of stupidity like<br>
><br>
> Kind of off-topic, but since you're mentioning overhead of hash tables:<br>
> I've been doing some work on util/hash_table that is yet to be sent to the list.<br>
> Thought I could share my experience if someone happens to be<br>
> working on other improvements to the hash-tables.<br>
><br>
> TLDR of approach:<br>
> Power-of-two sized table instead of prime size.<br>
> -> We can replace the modulo with bitmasking to fit keys in the table.<br>
> -> Reduced overhead on insert, search, resize, etc.<br>
> -> FNV-1a has good avalanche properties -> collisions is a no-issue.<br>
><br>
> Changing to quadratic probing removes the rehash-stuff.<br>
> -> Less code, simpler, seems to do a better job.<br>
> -> Reduced memory usage and better cache locality?<br>
><br>
> Preliminary oprofile results of a shader-db run with NIR:<br>
><br>
> hash_table_insert:   4.13 %   -->   2.13 %<br>
> hash_table_search: 4.12 %   -->   2.29 %<br>
><br>
> To be done:<br>
> Do the same for hash set.<br>
> Change some hash table uses to the one in util.<br>
> Similar treatment for the other tables.<br>
> Test on something that is actually CPU bound.<br>
<br>
Yeah, I was never convinced that the prime size hashtables provided<br>
any benefit. Sounds good to me looking forward to seeing the patches.<br>
<br>
Kristian<br>
<br>
> -Thomas Helland<br>
> _______________________________________________<br>
> mesa-dev mailing list<br>
> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</blockquote></div>