[Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)

[José Fonseca]

On Sun, 2010-08-01 at 10:19 -0700, Eric Anholt wrote:
> On Tue, 27 Jul 2010 21:32:57 +0100, José Fonseca <jfonseca at vmware.com> wrote:
> > 
> > On Wed, 2010-07-21 at 18:53 -0700, Ian Romanick wrote:
> > > As everyone knows, a group of us at Intel have been rewriting Mesa's
> > > GLSL compiler.  The work started out-of-tree as a stand alone compiler.
> > >  We moved all of our work to the glsl2 branch in the Mesa tree as soon
> > > as we had some actual code being generated.  This was about month ago.
> > > Since that time we have implemented quite a bit more code generation and
> > > a complete linker.  The compiler is not done, but it gets closer every day.
> > > 
> > > I think now is the time to start discussing merge criteria.  It is well
> > > known that the Intel graphics team favors quarterly releases.  In order
> > > to align with other people's release schedules, we'd really like to have
> > > the new compiler in a Mesa release at the end of Q3 (end of September /
> > > beginning of October).  That's just over two months from now.  In order
> > > to have a credible release, the compiler needs to be merged to master
> > > before then.  A reasonable estimate puts the end of August as the latest
> > > possible merge time.  Given how far the compiler has come in the last
> > > month, I have a lot of faith in being able to hit that target.
> > > 
> > > We have developed our own set of merge requirements, and these are
> > > listed below.  Since this is such a large subsystem, we want to solicit
> > > input from the other stakeholders.
> > > 
> > >  * No piglit regressions, except draw_buffers-05.vert, compared to
> > >     master in swrast, i965, or i915.
> > > 
> > >  * Any failing tests do not crash (segfault, assertion failure, etc.).
> > > 
> > > draw_buffers-05.vert is specifically excluded because I'm not sure the
> > > test is correct.
> > > 
> > > One of the items on the TODO list is proper support for GLSL ES.  That
> > > work won't happen until the last couple weeks of August, so I don't
> > > think any sort of ES testing is suitable merge criteria.  Unless, of
> > > course, the tests in question should also work on desktop GLSL.
> > > 
> > > We haven't and, for all practical purposes, can't test with Gallium or
> > > other hardware drivers.  The new compiler generates the same assembly IR
> > > that the current compiler generates.  We haven't added any instructions.
> > >  It does, however, generate different combinations of instructions,
> > > different uses of registers, and so on.  We don't expect there to be
> > > significant impact on other hardware, but there may be some.  The
> > > optimizer in r300 will certainly see different sequences of instructions
> > > than it is accustomed to seeing.  I can't foresee what impact this will
> > > have on that driver.
> > > 
> > > I have put up the results of master and the glsl2 branch at
> > > http://people.freedesktop.org/~idr/results/.  This run off
> > > compiler.tests from the glsl2 branch of Eric's piglit repository.  A few
> > > of the failures (half a dozen or so) on master seem to be mutex related
> > > in the GLX code.  Kristian is working on fixing that. :)
> > > 
> > > We're already very close to our proposed merge criteria.
> > 
> > I was recently made aware that glsl2 adds an hard dependency on the
> > talloc library. Is this correct?
> > 
> > I doesn't seem that talloc has ever been ported to Windows or MSVC,
> > although it seems small.
> > 
> > There's also the fact that it's a dependency with a very different
> > license from Mesa (LGPLv3). This is not an obstacle on itself, but it
> > makes it harder to simply bundle the code into mesa and port it
> > ourselves.
> > 
> > At a first glance it seems that talloc gives a tad more trouble than
> > what it's worth. Did you guys investigate other alternatives?  talloc.c
> > mentions it was inspired by http://swapped.cc/halloc/ , which is BSD
> > license and seems trivial to port to MSVC. Would that also fit your
> > needs?
> 
> No, it's missing most of the API that talloc provides.  Also,
> http://github.com/aras-p/glsl-optimizer/ ported it to windows.

Could then Aras Pranckevicius's talloc port to windows be merged into
glsl2 branch before glsl2 is merged into master?

Jose