On Tue, 27 Jul 2010 21:32:57 +0100, José Fonseca <jfons...@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.
pgpzMs2WHUjxw.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
