On Fri, 2012-08-24 at 11:21 -0700, Eric Anholt wrote: > Imre Deak <imre.d...@intel.com> writes: > > - if (values[table[hash & mask]].pname == d->pname) > > - break; > > - hash += prime_step; > > - j++; > > + if (values[TABLE_IDX(table[hash & mask])].pname == d->pname) > > + break; > > + hash += prime_step; > > + j++; > > indentation changes, fold them into the first patch.
Ok. > > > - if (likely(d->pname == pname)) > > + if (likely(d->pname == pname && (TABLE_API(table_val) & api_bit))) > > + /* > > + * Don't bail out here if the API doesn't match, since the same > > pname > > + * can be present in the table for other APIs (with different > > + * semantics). > > + */ > > break; > > How many of the pnames appear twice in the values table? AFAICS there are four such: GL_MAX_FRAGMENT_UNIFORM_VECTORS GL_MAX_VARYING_VECTORS GL_MAX_VERTEX_UNIFORM_VECTORS GL_SHADER_COMPILER Each with a GLES2 entry and a GL/GLES1 entry, the latter being enabled by the ARB_ES2_compatibility extension. > Would they be > better handled by doing some custom checking that was api-dependent, and > then not having the hash table be api-dependent? I guess this would mean checking the existence of the ARB_ES2_compatibility extension in case of GL/GLES1, so at least it seems to be easy to do. But the API info in the hash table for other entries is also used to merely check if the corresponding pname is valid in the caller's active API. But we could make the hash table API independent by having a separate table for each API, with a 2KiB overhead per API. I'm fine with this solution too if you think it's worth it. > It seems like it would be nice to do the hash table generation at build > time instead, so that it was constant data. Good idea, I could rework the patch accordingly. --Imre _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
