[Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
eric at anholt.net
Sun Aug 1 10:19:50 PDT 2010
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
> 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
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
Size: 197 bytes
Desc: not available
More information about the mesa-dev