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

[José Fonseca]

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?

Jose