|Summary:||[G45] Yo Frankie: problems with shaders|
|Product:||Mesa||Reporter:||Sven Arvidsson <sa>|
|Component:||Drivers/DRI/i965||Assignee:||Eric Anholt <eric>|
|Status:||RESOLVED FIXED||QA Contact:|
|i915 platform:||i915 features:|
|Bug Depends on:|
screenshot of the bug
correctly rendered in software
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 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 <email@example.com> 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.