headers
Dave Airlie | 1 Sep 2010 01:14
Picon
Gravatar

Re: [RFC] Mesa 7.9 release criteria

On Wed, Sep 1, 2010 at 6:57 AM, Ian Romanick <idr <at> freedesktop.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> We'd still like to release Mesa 7.9 at the end of September.  That's
> four weeks from now.  As soon as the glsl2-loops branch lands (I'm
> expecting this to be this week), all of the major development on the new
> compiler will be complete.  There's still a fair amount of bug fixing to
> be done, but that feels like the stabilization phase leading up to a
> release.
>
> Looking at the result of a bugzilla search for "glsl" I see a few
> categories of bugs:
>
>  - Old bugs.  Everything before #29044 was filed before the glsl2 work.
>  This accounts for almost half of the bugs (35 of 72).
>
>  - Bugs that only occur on softpipe or llvmpipe.  Since these bugs
> aren't reproducible in swrast, i965, or r300c, my first guess is that
> the problem is either in the Gallium code or the Mesa IR to TGSI
> translation layer.  Someone familiar with that code is going to have to
> do *some* leg work here.  It may not be (as was the case with reads from
> shader outputs), but I don't have the information to determine that.

I'm not sure softpipe should be considered "too hard to look at", its
just a sw renderer, it not hard to setup/install, and since r300g is
using the same IR->TGSI transform and we have people fixing bugs in
that. Its just C code, unfamiliar C code but its not like it needs hw
to run on.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Paul | 1 Sep 2010 03:24
Favicon

proper way to regenerate built-in functions?


I just fixed a bug in the atan() built-in function.  After editing the 
src/glsl/builtins/ir/atan file, I found that the only way to reliably 
rebuild everything was:

pushd src/glsl/; make clean; make builtins; make; popd; make

If I just did:

pushd src/glsl/; make; popd; make

I'd get runtime errors about bad IR code.

What's the proper way to regenerate everything after modifying a file 
like ir/atan?

-Brian
Permalink | Reply | 1 comment |
headers
bugzilla-daemon | 1 Sep 2010 03:30

[Bug 29910] Mesa advertises bogus GL_ARB_shading_language_120

https://bugs.freedesktop.org/show_bug.cgi?id=29910

--- Comment #2 from Brian Paul <brianp <at> vmware.com> 2010-08-31 18:30:55 PDT ---
Bruce, are you talking about seeing GL_ARB_shading_language_120 in the list of
extensions?

Ian is right that drivers would enable ctx->Extensions.ARB_shading_language_120
if they support it.

I see that NVIDIA doesn't list GL_ARB_shading_language_120 in the extension
string.  I guess we need some way to make this extension "invisible".

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
Brian Paul | 1 Sep 2010 03:35
Favicon

Re: [RFC] Mesa 7.9 release criteria

On 08/31/2010 02:57 PM, Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> We'd still like to release Mesa 7.9 at the end of September.  That's
> four weeks from now.  As soon as the glsl2-loops branch lands (I'm
> expecting this to be this week), all of the major development on the new
> compiler will be complete.  There's still a fair amount of bug fixing to
> be done, but that feels like the stabilization phase leading up to a
> release.
>
> Looking at the result of a bugzilla search for "glsl" I see a few
> categories of bugs:
>
>   - Old bugs.  Everything before #29044 was filed before the glsl2 work.
>   This accounts for almost half of the bugs (35 of 72).
>
>   - Bugs that only occur on softpipe or llvmpipe.  Since these bugs
> aren't reproducible in swrast, i965, or r300c, my first guess is that
> the problem is either in the Gallium code or the Mesa IR to TGSI
> translation layer.  Someone familiar with that code is going to have to
> do *some* leg work here.  It may not be (as was the case with reads from
> shader outputs), but I don't have the information to determine that.

I'm trying to look at some of these in my spare time.  But it's really 
easy to run the gallium softpipe driver, as Dave said.

>   - Additional regressions in applications that weren't completely
> correct with the old compiler.  As far as I'm aware, the regressions in
> the Humus and Unigen demos are all added failures.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Kenneth Graunke | 1 Sep 2010 03:54

Re: proper way to regenerate built-in functions?

On Tuesday 31 August 2010 18:24:53 Brian Paul wrote:
> I just fixed a bug in the atan() built-in function.  After editing the
> src/glsl/builtins/ir/atan file, I found that the only way to reliably
> rebuild everything was:
> 
> pushd src/glsl/; make clean; make builtins; make; popd; make

This is correct.  You can probably omit 'make clean', but otherwise, yes, 
that's what I do.  Then commit the updated builtin_function.cpp.

> If I just did:
> 
> pushd src/glsl/; make; popd; make
> 
> I'd get runtime errors about bad IR code.

Ideally this would work, but I haven't done the Makefile trickery to make it 
happen automatically.  Whenever any file in builtins/ changes, 
builtin_function.cpp needs to be regenerated...but that process uses 
glsl_compiler.  So first, 'make builtins' builds a bare-bones compiler using a 
dummy copy of builtin_function.cpp (with no built-ins), then uses that 
compiler to build the proper source (with all the functions).  Once it's 
built, it goes ahead and rebuilds the compiler against the newly generated 
file.

I'm sure there's a way to set up the Makefile dependencies to do the proper 
bootstrapping, but I haven't gotten around to it.  Patches are welcome...

> What's the proper way to regenerate everything after modifying a file
> like ir/atan?
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Sep 2010 03:57

[Bug 29793] [glsl2]piglit glslparsertest_glsl2_struct-05.vert and glslparsertest_glsl2_redeclaration-02.vert fail

https://bugs.freedesktop.org/show_bug.cgi?id=29793

fangxun <xunx.fang <at> intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |VERIFIED

--- Comment #3 from fangxun <xunx.fang <at> intel.com> 2010-08-31 18:57:56 PDT ---
It works fine now. Mark it as verified.

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
Dave Airlie | 1 Sep 2010 08:14
Picon
Gravatar

vertex shader that processes 0 vertex data

I was looking at glsl-vs-point-size in piglit today and it doesn't
work on gallium.

void main()
{
        gl_Position = vec4(0.0, 0.0, 0.0, 1.0);
        gl_PointSize = 16.0;
        gl_FrontColor = vec4(1.0, 1.0, 1.0, 1.0);
}

Since the vertex shader doesn't have any declared inputs,

we work out the vp in gallium and then in st_draw.c:st_draw_vbo we hit

   if (num_vbuffers == 0 || num_velements == 0)
      return;

Any ideas on what should happen here?

Dave.
Permalink | Reply | 2 comments |
headers
keith whitwell | 1 Sep 2010 09:17
Picon

Re: vertex shader that processes 0 vertex data

On Wed, Sep 1, 2010 at 7:14 AM, Dave Airlie <airlied <at> gmail.com> wrote:
> I was looking at glsl-vs-point-size in piglit today and it doesn't
> work on gallium.
>
> void main()
> {
>        gl_Position = vec4(0.0, 0.0, 0.0, 1.0);
>        gl_PointSize = 16.0;
>        gl_FrontColor = vec4(1.0, 1.0, 1.0, 1.0);
> }
>
> Since the vertex shader doesn't have any declared inputs,
>
> we work out the vp in gallium and then in st_draw.c:st_draw_vbo we hit
>
>   if (num_vbuffers == 0 || num_velements == 0)
>      return;
>
> Any ideas on what should happen here?
>

I hadn't really considered this case, but it's clearly valid.  What
should be happening seems clear - there should be zero vertex buffers
bound and zero vertex elements referencing them and the draw call
should be legal.

Basically, the test above is incorrect and should be removed.  I
suspect the same assumption is built in elsewhere in the code and
you'll hit a few asserts and crashes in the process of getting this
working.
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Sep 2010 09:25

[Bug 29910] Mesa advertises bogus GL_ARB_shading_language_120

https://bugs.freedesktop.org/show_bug.cgi?id=29910

--- Comment #3 from Bruce Merry <bmerry <at> gmail.com> 2010-09-01 00:25:15 PDT ---
> Bruce, are you talking about seeing GL_ARB_shading_language_120 in the list of
extensions?

Sorry yes, that's what I meant: it's the fact that it's showing up in
GL_EXTENSIONS that is a bug. I haven't looked at the internal interfaces
between drivers and the core.

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Sep 2010 16:49

[Bug 29282] Various cygwin mklib/minstall fixes

https://bugs.freedesktop.org/show_bug.cgi?id=29282

Brian Paul <brianp <at> vmware.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #6 from Brian Paul <brianp <at> vmware.com> 2010-09-01 07:49:30 PDT ---
These look OK to me so I'll apply them.

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |

Gmane