[Mesa-dev] [PATCH 3/3] mesa: glGet: fix parameter lookup for apps using multiple APIs

[Imre Deak]

On Fri, 2012-08-24 at 11:21 -0700, Eric Anholt wrote:
> Imre Deak <imre.deak at 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