[Mesa-dev] [RFC 08/21] mesa/extensions: Replace extension::api_set with ::version

Chad Versace chad.versace at intel.com
Thu Oct 22 11:39:15 PDT 2015


On Thu 22 Oct 2015, Matt Turner wrote:
> On Thu, Oct 22, 2015 at 11:24 AM, Chad Versace <chad.versace at intel.com> wrote:
> > On Mon 19 Oct 2015, Nanley Chery wrote:
> >> From: Nanley Chery <nanley.g.chery at intel.com>
> >>
> >> The api_set field has no users outside of _mesa_extension_supported().
> >> Remove it and allow the version field to take its place.
> >>
> >> The brunt of the transformation was performed with the following vim commands:
> >> s/\(GL [^,]\+\),\s*\d*,\s*\d*\(,\s*\d*\)\(,\s*\d*\)/\1, GLL, GLC\2\3/g
> >> s/\(GLL [^,]\+\)\,\s*\d*/\1, GLL/g
> >> s/\(GLC [^,]\+\)\(,\s*\d*\),\s*\d*\(,\s*\d*\)\(,\s*\d*\)/\1\2, GLC\3\4/g
> >> s/\( ES1[^,]*\)\(,\s*\(\w\|\d\)\+\)\(,\s*\(\w\|\d\)\+\),\s*\d*/\1\2\4, ES1/g
> >> s/\( ES2[^,]*\)\(,\s*\(\w\|\d\)\+\)\(,\s*\(\w\|\d\)\+\)\(,\s*\(\w\|\d\)\+\),\s*\d*/\1\2\4\6, ES2/g
> >>
> >> Signed-off-by: Nanley Chery <nanley.g.chery at intel.com>
> >> ---
> >>  src/mesa/main/extensions.c       |  21 +-
> >>  src/mesa/main/extensions_table.h | 636 ++++++++++++++++++++-------------------
> >>  2 files changed, 326 insertions(+), 331 deletions(-)
> >
> > [...]
> >
> >> diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
> >
> > [...]
> >
> >> +#define GLL 0
> >> +#define GLC 0
> >> +#define ES1 0
> >> +#define ES2 0
> >> +#define  x ~0
> >
> >> +EXT(EXT_abgr                                , dummy_true                             , GLL, GLC,  x ,  x , 1995)
> >> +EXT(EXT_bgra                                , dummy_true                             , GLL,  x ,  x ,  x , 1995)
> >> +EXT(EXT_blend_color                         , EXT_blend_color                        , GLL,  x ,  x ,  x , 1995)
> >> +EXT(EXT_blend_equation_separate             , EXT_blend_equation_separate            , GLL, GLC,  x ,  x , 2003)
> >> +EXT(EXT_blend_func_separate                 , EXT_blend_func_separate                , GLL,  x ,  x ,  x , 1999)
> >> +EXT(EXT_discard_framebuffer                 , dummy_true                             ,  x ,  x , ES1, ES2, 2009)
> >> +EXT(EXT_blend_minmax                        , EXT_blend_minmax                       , GLL,  x , ES1, ES2, 1995)
> >
> > I like the idea of this patch. It's a cleanup that needs to happen. But,
> > the little details confuse me.
> >
> > When I see GLL, GLC, ES1, and ES2 as the entries in the version columns,
> > the entries confuse me because I expect the tokens to all have different
> > values. Otherwise, why would the tokens have different names?
> >
> > I think the table would be less confusing if you used the macros
> >   #define x ~0
> >   #define Y 0
> > or
> >   #define n ~0
> >   #define Y 0
> > or
> >   #define n ~0
> >   #define y 0
> > or anything like that. I like the n/Y the best because the letters are
> > mnenomic and the contrast of uppercase to lowercase is easy to see when
> > scanning the table.
> 
> I get what you're saying, but Nanley's code as is allows you to see
> exactly which APIs an extension exists in without looking up the
> column headers.

You make a good point.

> With your approach, a reader would need to know that the columns are
> ordered GL compat, GL core, ES1, ES2, if I've understood your
> suggestion.

You understood my suggestion correctly.

In the giant table contained in brw_surface_formats.c, we solve the
readability problem by inserting a banner comment at semi-regular intervals,
about every 40 lines. Like this:

   SF( x,  x,  x,  x,  x,  x,  Y,  x,  x, R8G8_SSCALED)
   SF( x,  x,  x,  x,  x,  x,  Y,  x,  x, R8G8_USCALED)
/* smpl filt shad CK  RT  AB  VB  SO  color */
   SF( x,  x,  x,  x,  x,  x,  Y,  x,  x, R16_SSCALED)
   SF( x,  x,  x,  x,  x,  x,  Y,  x,  x, R16_USCALED)
   SF(50, 50,  x,  x,  x,  x,  x,  x,  x, P8A8_UNORM_PALETTE0)
   SF(50, 50,  x,  x,  x,  x,  x,  x,  x, P8A8_UNORM_PALETTE1)

But, as you pointed out, Nanley's solution obviates the need for the banner
comment. And banner comments are clumsy. So I drop my suggestion.


More information about the mesa-dev mailing list