There are lots of varyings. Just a guess - aren't there more vertex shader outputs than we can rasterize? We are currently limited to 8 generics.

RADEON_DEBUG=rs shows 7 generics written to FS, I guess that's the problem.

r300: Rasterized generic 0 unused.
r300: Rasterized generic 10 written to FS.
r300: Rasterized generic 11 written to FS.
r300: Rasterized generic 12 written to FS.
r300: Rasterized generic 13 written to FS.
r300: Rasterized generic 14 written to FS.
r300: Rasterized generic 15 written to FS.
r300: Rasterized generic 16 written to FS.
r300: FS input generic 17 unassigned.
r300: FS input generic 18 unassigned.
r300: FS input generic 19 unassigned.
r300: FS input generic 20 unassigned.
r300: FS input generic 21 unassigned.
r300: FS input generic 22 unassigned.
r300: --- Rasterizer status ---: colors: 0, generics: 8.

As you know, I have an r300 video card and I am using git mesa, so if you need any testing, just let me know..

(In reply to comment #1)
> There are lots of varyings. Just a guess - aren't there more vertex shader
> outputs than we can rasterize? We are currently limited to 8 generics.

KWin generates the source code for the blur shaders at runtime and should limit the number of varyings to GL_MAX_VARYING_FLOATS / 4.

So I don't think this is the explanation for why it's not working in KWin (although the piglit test I submitted obviously uses too many).

Anyway I'll submit another testcase that uses 8 varyings.

Any news on this?
Blur is still broken in kwin-4.5.1 on my mobility x700 using r300g from the latest mesa git..

(In reply to comment #5)
> (In reply to comment #1)
> > There are lots of varyings. Just a guess - aren't there more vertex shader
> > outputs than we can rasterize? We are currently limited to 8 generics.
> 
> KWin generates the source code for the blur shaders at runtime and should limit
> the number of varyings to GL_MAX_VARYING_FLOATS / 4.
> 
> So I don't think this is the explanation for why it's not working in KWin
> (although the piglit test I submitted obviously uses too many).
> 
> Anyway I'll submit another testcase that uses 8 varyings.

I've pushed another piglit test that uses 7 varyings to:

http://cgit.freedesktop.org/~fredrik/piglit

While I was looking at the code for the vertex shader I also realized that it was setting gl_TexCoord[0] even though the fragment shader wasn't using it. I've fixed that in kwin and updated the code in the original piglit test to reflect that change.

The number of varyings used is always an odd number, so even with gl_texCoord[0] being set the available outputs shouldn't have been exceeded though.

Actually, all vertex shader outputs are sent to the rasterizer in r300g and therefore they occupy texcoord slots. We cannot disable unused outputs via some hardware state, but I guess we could recompile the vertex shader based on what inputs are read by the fragment shader.

Hi, 

I did a git bisect (only on src/gallium, I have some problem doing it for the whole mesa since it doesn't compile :

radeong_dri.so.tmp: undefined reference to `operator delete[](void*)'
radeong_dri.so.tmp: undefined reference to `operator delete(void*)'
radeong_dri.so.tmp: undefined reference to `operator new[](unsigned long)'
radeong_dri.so.tmp: undefined reference to `__cxa_pure_virtual'
radeong_dri.so.tmp: undefined reference to `__gxx_personality_v0'
radeong_dri.so.tmp: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info'
radeong_dri.so.tmp: undefined reference to `vtable for __cxxabiv1::__class_type_info'
radeong_dri.so.tmp: undefined reference to `vtable for __cxxabiv1::__si_class_type_info'

(ca088cc277ce9f986693c857f3961dc0e1a4d91c and previous)).

Anyway, here is the partial result:

4f51762b070854901b48e461b76f614da414868d is the first bad commit
commit 4f51762b070854901b48e461b76f614da414868d
Author: Jakob Bornecrantz <jakob@vmware.com>
Date:   Thu Aug 12 13:51:39 2010 +0100

    gallium: Link DRI drivers with g++ and test with CXX
    
    New shader compiler need libc++ runtime. This works already if
    we are using llvm so this just covers the !llvm case.

:040000 040000 bb2d7003cbdb5dc4aa8b173d1137c2461e255d76 e6558a2a178ab07006ab69cb9326278de84b817c M      src
[clement@euryphaessa mesa]$ git bisect log
# bad: [09547e1bcee7df3444dd8682770d1b31da1a5822] r600g : add basic loop support.
# good: [1cb92fb92e69b5b138293398a98665c2a3c63a5b] translate_generic: factor out common code between linear and indexed
# good: [e01a49af61a4d56800b1ad672959ba7a88c1da1e] r300g: Remove unnecessary header.
git bisect start '09547e1bcee7df3444dd8682770d1b31da1a5822' '1cb92fb92e69b5b138293398a98665c2a3c63a5b' 'e01a49af61a4d56800b1ad672959ba7a88c1da1e' '--' 'src/gallium/'
# bad: [d843bbfd3f92d5afea665c3ff16bcca0628f2e7b] r600g: fix DB decompression
git bisect bad d843bbfd3f92d5afea665c3ff16bcca0628f2e7b
# bad: [bed9dff9d94e33d34340183d7cb633869dcb4f90] u_debug_describe: use switch instead of if chain
git bisect bad bed9dff9d94e33d34340183d7cb633869dcb4f90
# bad: [076c53879b90855ecf38602584f22e4ab6db7569] r600g: update comments about ALU src operands
git bisect bad 076c53879b90855ecf38602584f22e4ab6db7569
# bad: [1c2a44e445fa4d3bd6f95d9c63041c222268724a] r300g: fix context destroy under hyperz
git bisect bad 1c2a44e445fa4d3bd6f95d9c63041c222268724a
# good: [ecec6df9cfe74dbd16f072bc4bbcd90374f8d2c8] r300g: fix assert in the rasterizer block for r3xx-r4xx
git bisect good ecec6df9cfe74dbd16f072bc4bbcd90374f8d2c8
# bad: [1d22923fae7f4c749b3820844110e3d8ee4d26c0] scons: Link talloc.
git bisect bad 1d22923fae7f4c749b3820844110e3d8ee4d26c0
# bad: [3a3cdb909da5b02edf921fcb5a009dfc2868d23d] scons: Build the new glsl2 code.
git bisect bad 3a3cdb909da5b02edf921fcb5a009dfc2868d23d
# bad: [4f51762b070854901b48e461b76f614da414868d] gallium: Link DRI drivers with g++ and test with CXX
git bisect bad 4f51762b070854901b48e461b76f614da414868d

Also, I noticed that the blur effect never worked perfectly: it works if you put the strength of the effect <= the average strength (you can choose the strength of the effect in systemsettings, the more it is set, the more it's blured (yeah, really, crazy huh?)). Otherwise, you see artifacts. Dunno why though, but just thought it might be a pointer. 

Ah, and last thing, I run kde 4.5.75.

Voilà, if you need anything else, don't hesitate, I'd really like to have the blur effect working, it's way more beautiful.

Is this still an issue with current Mesa git?

The blur effect works for me with kwin 4.5.1 on R5xx.

Works with KDE 4.5.85 and a x1400 mobility (so also a r5XX afaik). Thanks a lot :)

Fredrik, I have pushed your kwin tests update to piglit now (sorry I overlooked it).

Clément, thanks for the feedback. I consider this issue closed as far as r5xx chipsets are concerned.

davide, does the blur effect work for you with the latest mesa master branch on your ATI X700?

So far there's no feedback from davide and nobody else appears to have any issue with the blur, so I am closing the bug. Please re-open this bug (or better: file a new one) if it doesn't work on r3xx-r4xx.