Created attachment 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. I don't know if there a bug in that patch, or it exposed another bug (maybe even the bug that caused the random texture in the first place?)
(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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.