[Mesa-dev] Merge criteria for glsl2 branch

[Eric Anholt]

On Thu, 22 Jul 2010 08:01:30 -0600, Brian Paul <brianp at vmware.com> wrote:
> On 07/21/2010 07:53 PM, Ian Romanick wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > 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.).
> 
> Please add the mesa-demos/src/glsl/ tests to your list of test apps, 
> if you haven't already.

I ran most of them and they basically look OK (mandelbrot's wrong on 965
but not swrast), but they aren't going to be tested regularly unless
someone moves them to piglit.

> Which driver are you using for testing?
> 
> Your web page shows a bunch of glean/glsl1 failures but with swrast 
> here, there are no failures (two fails with softpipe due to error in 
> log/exp).
> 
> It's important that the glean glsl1 tests pass since many of them 
> exercise things I found in various apps.  I seem to remember the 
> Lightsmark benchmark uses quite a few interesting shaders.

We'd use swrast for those tests that fail due to driver bugs (we're
doing that for several tests already, such as the piglit function calls
ones), but swrast produces GL visuals with alpha bits even though it
can't actually write alpha bits to a depth 24 drawable.  So the glean
tests we force to software fail anyway because the alpha values probed
are wrong.

If someone could sort that out, it would be great for our testing.  One
still not-quite-conformant option would be to have swrast just hang on
to a buffer of the pixel values and operate on that, instead of doing
get/put image.  It should be better performance, too.
-------------- 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/20100723/f9824412/attachment.pgp>