[Mesa-dev] The get/get_hash_params situation...

[Kenneth Graunke]

On Saturday, January 23, 2016 9:49:24 AM PST Ilia Mirkin wrote:
> ... sucks. Every change to that file is an exercise in pain. We want
> more and more complex checks on all the various enums, as they tend to
> appear in GL core with ext A or in GL ES with ext B but only if ES >
> 3.1, and not if the moon is waxing, etc.
> 
> Any objections if I rewrite it to be not so annoying to use? I see
> that it does some very clever things with hashing that I can't even
> begin to work out. Obviously glGet* should be fast, but as long as a
> reimplementation keeps to that basic tenet, is there anything else I
> should be aware of? Are there specific performance considerations?
> 
>   -ilia

That sounds good to me.  The "extra" stuff is pretty painful.
It seems like using predicate functions would be a lot nicer:

static inline bool has_tessellation(const struct gl_context *);

then you could put whatever arbitrary checks you need, without
having to try and remember whether the items in each "extra" list
are combined with ||, or &&, or what.  I guess we can't inline them
with the hash table approach, though (while we could with a switch
statement)...so it'd probably mean a function pointer call.

Honestly, there have been a lot of changes to that file that I feel
haven't been adequately explained.  We originally had a python script
that generated a giant switch statement.  In 2010, krh removed the
python and introduced the current hash approach, with a commit titled
"mesa: Optimize get.c by using a table-driver approach".  I think part
of the reason for that was to get rid of generator scripts, and just
write ordinary C code (though it doesn't say that).  In 2012, Imre
moved us back to python generators (mesa: glGet: add script to
generate hash tables in build time).  Presumably this was to eliminate
context creation overhead, but again, the history doesn't exactly say...

I'll be interested to see what you come up with.  Maybe send a draft of
your idea so people can take a look before you bother to convert the
whole thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20160123/87002376/attachment.sig>