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

[Eric Anholt]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100801/3e0e998a/attachment.pgp>