On Fri, May 19, 2017 at 05:32:07PM -0700, Ian Romanick wrote: > On 05/19/2017 05:07 PM, Ilia Mirkin wrote: > > On Fri, May 19, 2017 at 7:29 PM, Ian Romanick <i...@freedesktop.org> wrote: > >> I missed that glsl_parser_extras.cpp has its own implementation of the > >> has_XXX_foo() functions that take the API and version as explicit > >> parameters. Your patch predates that change. There's room for some > >> modest savings there too. > > > > The main thing about those functions is that they have to be > > out-of-line, as they're invoked via function pointer. Each one can be > > cut down a little using your approach of statically looking at the cap > > restrictions, but I don't think inlining can work. [I added that code > > to (a) add "permission" checks to enable extensions in glsl and (b) > > remove the duplication of adding #defines for all the ext names.] > > Right. I think there's two approaches to try. The least intrusive is > to try some of these tricks in the existing functions. The more > intrusive would be to generate the data into the table and modify > _mesa_glsl_extension::compatible_with_state to use the data instead of > calling the function. > > I'm leaning towards the latter, but I haven't decided how I'd want to > generate the data. The method used by other users of > main/extensions_table.h won't work because we only want a subset of > extensions. Hmm... >
I'll have to get back to this next week, but please don't feel blocked on my comments. This may be the latter trick mentioned above, but if it isn't, a third option is to initialize an array at context creation time to describe which extensions are supported. That array is then looked up in the helpers: https://cgit.freedesktop.org/~nchery/mesa/log/?h=3/ext/init _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev