Bug 29263

(In reply to comment #0)
> Created an attachment (id=37398) [details]
> glxinfo, Xorg.0.log, dmesg
> 
> I just started shadowtex today and got this assertion failure.
> ./shadowtex 
> Using GL_ARB_depth_texture
> and GL_ARB_shadow
> and GL_ARB_fragment_program
> and GL_ARB_shadow_ambient
> Using GL_EXT_framebuffer_object
> Keys:
>   a = toggle animation
>   i = show depth texture image
>   m = show depth texture mapping
>   d = show fragment distance from light source
>   n = show normal, shadowed image
>   f = toggle nearest/bilinear texture filtering
>   b/B = decrease/increase shadow map Z bias
>   p = toggle use of packed depth/stencil
>   M = cycle through fragment program modes
>   v = toggle vertex program modes
>   cursor keys = rotate scene
>   <shift> + cursor keys = rotate light source
>   o = cycle through comparison modes
> Rendering 256 x 256 depth texture
> shadowtex: r700_assembler.c:6355: Process_Export: Assertion
> `starting_register_number >= pAsm->starting_export_register_number' failed.
> Aborted
> 
> Steps to reproduce:
> 1 Build mesa for r600:
> $ ./configure --prefix=/opt/xorg --with-dri-drivers=r600,swrast
> --disable-gallium --with-dri-driverdir=/opt/xorg/lib/dri --enable-glx-tls
> PKG_CONFIG_PATH=/opt/xorg/lib/pkgconfig/
> $ make clean
> $ make -j8
> $ make install
> 2 Run shadowtex demo
> $ cd /path/to/mesa/demos
> $ ./shadowtex
> 
> I remember shadowtex working at some point (and works with 7.8.x). "Works" in
> the sense that it renders something, the shadow texture itself is random (see
> bug #26735). But it was certainly not aborting.
> So I did a git bisect and it came up with this:
> 
> b6b9b17d27c570cc99ae339e595cf2f63ca5e8d7 is the first bad commit
> commit b6b9b17d27c570cc99ae339e595cf2f63ca5e8d7
> Author: Brian Paul <brianp@vmware.com>
> Date:   Fri Jul 2 08:14:54 2010 -0600
> 
>     mesa: make the number of draw buffers part of the texenv program key state
> 
>     All the state that effects the program should be in the key.
>     This didn't help with bug 28169 but is a good fix anyway.
> 
>     NOTE: this is a low-priority candidate for the 7.8 branch.  In practice,
>     this issue might never be hit.
> 
> :040000 040000 c9f1d363565e225cdf17e57993b6a773a46107c5
> 3e22c4d9a51ba9b569ee72ba2fa2a1186f41a30d M      src
> 
> Reverting that patch makes it work again.

reverting in the sense of checking out its parent, 'git revert' can't cleanly revert that patch (I get build error).

The commit from bisect does not look like the real cause.
Should be fixed by 9b3bf392e1af72d29afa0804260cac4d8ffe24e1

Andre

(In reply to comment #2)
> The commit from bisect does not look like the real cause.
> Should be fixed by 9b3bf392e1af72d29afa0804260cac4d8ffe24e1
> 
> Andre

Thanks, that fixed the assert.