[Mesa-dev] Merge criteria for glsl2 branch

[Brian Paul]

On 07/23/2010 02:04 PM, Eric Anholt wrote:
> 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.

I haven't tried it recently, but the MESA_GLX_FORCE_ALPHA env var, if 
set, should add software alpha planes if you're using the Xlib driver.

-Brian