Bug 27143 - [G45] Yo Frankie: problems with shaders
Summary: [G45] Yo Frankie: problems with shaders
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Eric Anholt
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 29044
  Show dependency treegraph
 
Reported: 2010-03-17 15:36 UTC by Sven Arvidsson
Modified: 2010-10-14 12:43 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
screenshot of the bug (328.10 KB, image/png)
2010-03-17 15:36 UTC, Sven Arvidsson
Details
correctly rendered in software (443.78 KB, image/png)
2010-03-17 15:36 UTC, Sven Arvidsson
Details
shader_lava.py (1.62 KB, text/plain)
2010-03-17 15:36 UTC, Sven Arvidsson
Details
shader_uvtx.py (1.38 KB, text/plain)
2010-03-17 15:37 UTC, Sven Arvidsson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Arvidsson 2010-03-17 15:36:06 UTC
Created attachment 34165 [details]
screenshot of the bug

The shaders in the game Yo Frankie isn't rendered correctly, the player and the signs in the first level are mostly black.

This is only a problem if graphics is set to "high" in the options.

I'm attaching screenshots of the problem with a comparison from running the game with the software rasterizer. I'm also attaching two python scripts which includes the shaders the game is using.
Comment 1 Sven Arvidsson 2010-03-17 15:36:37 UTC
Created attachment 34166 [details]
correctly rendered in software
Comment 2 Sven Arvidsson 2010-03-17 15:36:59 UTC
Created attachment 34167 [details]
shader_lava.py
Comment 3 Sven Arvidsson 2010-03-17 15:37:25 UTC
Created attachment 34168 [details]
shader_uvtx.py
Comment 4 Eric Anholt 2010-03-19 13:36:58 UTC
From the debugging I'd done before, I don't think those are the only shaders the game uses, and unlikely to be the ones on the signs.  For example, the previous failure was with sqrt() which doesn't appear there.
Comment 5 Sven Arvidsson 2010-03-19 14:54:47 UTC
I see, then I guess those shaders are internal to the Blender Game Engine, which probably makes it much harder to track down...
Comment 6 Sven Arvidsson 2010-03-19 16:35:36 UTC
It's probably possible to make tracking this down a lot easier by opening the parts of the game effected by the bug in Blender and then dump the shaders.

But this will have to wait until bug #27034 is resolved. 
Comment 7 Sven Arvidsson 2010-03-23 14:47:40 UTC
I tried removing everything except the character from the scene, and then logging the shaders, but still ended up with over 15k lines of code, so clearly that's not the way to go.
Comment 8 Eric Anholt 2010-08-17 09:25:12 UTC
MESA_GLSL=dump now dumps shader source.  I've used it for looking at Yo Frankie's shaders and optimizing some of the things that it does, but it's really hard to make sense of what would be going wrong in a 1500-line shader.
Comment 9 Eric Anholt 2010-10-03 01:16:27 UTC
This is fixed in the new FS backend.
Comment 10 Eric Anholt 2010-10-14 12:43:33 UTC
commit a81d423d93f22a948f3aa4bf73dc6b1a3b70192f
Author: Eric Anholt <eric@anholt.net>
Date:   Thu Oct 14 12:23:29 2010 -0700

    i965: Enable the new FS backend on pre-gen6 as well.
    
    It is now to the point where we have no regressing piglit tests.  It
    also fixes Yo Frankie! and Humus DynamicBranching, probably due to the
    piglit bias tests that work that didn't on the Mesa IR backend.
    
    As a downside, performance takes about a 5-10% performance hit at the
    moment (e.g. nexuiz 19.8fps -> 18.8fps), which I plan to resolve by
    reintroducing 16-wide fragment shaders where possible.  It is a win,
    though, for fragment shaders using flow control.


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.