| Summary: | r300_fragprog_emit.c::emit_alu(): Too many ALU instructions | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Ionut Biru <biru.ionut> |
| Component: | Drivers/Gallium/r300 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED NOTABUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 7.10 | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
xorg log
preview of the bug log generated using RADEON_DEBUG=fp when using gnome-shell The shader in question before and after our suggestions |
||
Created attachment 44403 [details]
preview of the bug
Can you set the environment variable RADEON_DEBUG=fp and post the .xsession-errors file? Created attachment 44404 [details]
log generated using RADEON_DEBUG=fp when using gnome-shell
Like Marek said, this isn't a bug it is a hardware limitation. The only way this could work is with changes to Gnome Shell, so you should contact the Gnome Shell developers, although they might tell your hardware is unsupported. (In reply to comment #4) > Like Marek said, this isn't a bug it is a hardware limitation. The only way > this could work is with changes to Gnome Shell, so you should contact the Gnome > Shell developers, although they might tell your hardware is unsupported. Since we know there's a lot of work still to be done in the compiler's higher level optimization passes, I always feel like this is a bit of a cop out answer. The TGSI input is 125 instructions, and it looks like a nightmare of lowered if-statements. There are way more CMP/SEQ/MUL sequences than any program should generate. Unsurprisingly, the driver chokes on it. I'm sure the i915 driver, which has limitations similar to r300, would choke even worse. Comparing the GLSL to the generated TGSI might reveal some high-level optimization opportunities that we're missing. It may also help us give some suggestions to the gnome-shell folks to make the shader more friendly to older hardware. There are, after all, a lot of i915s and r300s out there. Just for giggles, could we get the output of MESA_GLSL=dump too? Use the same procedure as for RADEON_DEBUG=fp. @Ian (In reply to comment #5) > (In reply to comment #4) > > Like Marek said, this isn't a bug it is a hardware limitation. The only way > > this could work is with changes to Gnome Shell, so you should contact the Gnome > > Shell developers, although they might tell your hardware is unsupported. > my problem was fixed by gnome-shell developers by reducing the number of shader. http://git.gnome.org/browse/gnome-shell/commit/?id=43cf60f5636e7883bd5012e4c89ed5d57e28200c > Since we know there's a lot of work still to be done in the compiler's higher > level optimization passes, I always feel like this is a bit of a cop out > answer. The TGSI input is 125 instructions, and it looks like a nightmare of > lowered if-statements. There are way more CMP/SEQ/MUL sequences than any > program should generate. Unsurprisingly, the driver chokes on it. I'm sure > the i915 driver, which has limitations similar to r300, would choke even worse. > > Comparing the GLSL to the generated TGSI might reveal some high-level > optimization opportunities that we're missing. It may also help us give some > suggestions to the gnome-shell folks to make the shader more friendly to older > hardware. There are, after all, a lot of i915s and r300s out there. > > Just for giggles, could we get the output of MESA_GLSL=dump too? Use the same > procedure as for RADEON_DEBUG=fp. sure. i would do it (In reply to comment #5) > (In reply to comment #4) > > Like Marek said, this isn't a bug it is a hardware limitation. The only way > > this could work is with changes to Gnome Shell, so you should contact the Gnome > > Shell developers, although they might tell your hardware is unsupported. > > Since we know there's a lot of work still to be done in the compiler's higher > level optimization passes, I always feel like this is a bit of a cop out > answer. The TGSI input is 125 instructions, and it looks like a nightmare of > lowered if-statements. There are way more CMP/SEQ/MUL sequences than any > program should generate. Unsurprisingly, the driver chokes on it. I'm sure > the i915 driver, which has limitations similar to r300, would choke even worse. > > Comparing the GLSL to the generated TGSI might reveal some high-level > optimization opportunities that we're missing. It may also help us give some > suggestions to the gnome-shell folks to make the shader more friendly to older > hardware. There are, after all, a lot of i915s and r300s out there. > > Just for giggles, could we get the output of MESA_GLSL=dump too? Use the same > procedure as for RADEON_DEBUG=fp. We were able to give some suggestions to the gnome shell developers to get the shader to fit. The optimization that is missing is pre-computing of equivalent expressions (not sure what the technical term is). In this shader there was a four clause conditional that was being used in two different IF statements. I've attached the before and after versions of the shader if you're interested Created attachment 44454 [details]
The shader in question before and after our suggestions
(In reply to comment #7) > We were able to give some suggestions to the gnome shell developers to get the > shader to fit. The optimization that is missing is pre-computing of equivalent > expressions (not sure what the technical term is). Common subexpression elimination. |
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.
Created attachment 44402 [details] xorg log when using gnome shell 2.91.91, clicking on Applications, in the location where the icons should be listed,i have a big black square. Clicking on the other categories the icons are show normally, only the All category has this problem .xsession-errors has r300 FP: Compiler Error: r300_fragprog_emit.c::emit_alu(): Too many ALU instructions Using a dummy shader instead. mesa 7.10.1 clutter 1.6.8