[Mesa-dev] [PATCH 2/2] intel: add ANGLE_texture_compression_dxt extension support.

[Oliver McFadden]

On Thu, Sep 06, 2012 at 08:37:35AM +0300, Oliver McFadden wrote:
> On Wed, Sep 05, 2012 at 08:11:55AM -0600, Brian Paul wrote:
> > On 09/05/2012 03:38 AM, Oliver McFadden wrote:
> > > On Tue, Sep 04, 2012 at 12:41:12PM -0600, Brian Paul wrote:
> > >> On 09/04/2012 12:08 PM, Ian Romanick wrote:
> > >>> On 09/04/2012 08:16 AM, Brian Paul wrote:
> > >>
> > >>
> > >>>> Most of the patch is 'FEATURE_x' changes. I've been tempted to rip out
> > >>>> all that stuff.
> > >>>>
> > >>>> The original idea was to make it easy for people to build smaller Mesa
> > >>>> subsets (and the ES subset) by running the code through the
> > >>>> preprocessor
> > >>>> with all the FEATURE_x flags set on/off as needed. In the past some
> > >>>> people were really concerned about code size for static analysis and to
> > >>>> minimize binary sizes. I haven't heard any concerns about that in a
> > >>>> long time. If someone's really determined to make a tighter subset,
> > >>>> they'd have to go above and beyond turning off FEATURE_x flags anyway.
> > >>>>
> > >>>> And now, we're building one library that supports runtime selection of
> > >>>> full OpenGL profiles, core profiles and ES profiles. The FEATURE stuff
> > >>>> doesn't add any value for that and seems more trouble than it's worth.
> > >>>>
> > >>>> Any other opinions?
> > >>>
> > >>> I'm not a fan of the fine-grained FEATURE_x bits. If we had just a
> > >>> couple (like FEATURE_ES2) that were actually maintained, I could see
> > >>> the potential for value. As it is, I think it just adds maintenance
> > >>> burden.
> > >>
> > >> OK. Any volunteers to start removing the FEATURE_x lines?
> > >
> > > If nobody else wants to take this work, I'll do it. I suspect most if it
> > > could be done with unifdef (or sed) and possible white-space cleanup
> > > afterwards.
> > >
> > > Would you prefer one big "nuke all FEATURE_* defines" patch, or
> > > individual patches "remove FEATURE_a define", "remove FEATURE_b define",
> > > etc. (Obviously excluding the useful ones, _GL, _ES1, _ES2.)
> > >
> > > It doesn't make much difference to the amount of work for me.
> > 
> > I'd do it in a few chunks/patches at least (to aid in bisection if 
> > needed.)
> 
> Agree.
> 
> > 
> > Whether you do it file-by-file or FEATURE-by-FEATURE is up to you.  Be 
> > careful with the FEATURE_remap_table flag too, I think that one's a 
> > little tricky.
> 
> OK, thanks for the warning. I will do it FEATURE-by-FEATURE,
> file-by-file shouldn't be how Git is used, and anyway I'd probably still
> have to do FEATURE-by-FEATURE within those files...

I apologize for the delay in making and sending out the patches. I have
been quite sick and am just now recovering. I should be sending
something out tomorrow, Tuesday, GMT+3 afternoon/evening.

> 
> -- 
> Oliver McFadden.

-- 
Oliver McFadden.