Created attachment 123291 [details] API trace of the crash. Only 2 frames long. After building the very latest code for GLideN64 (https://github.com/gonetz/GLideN64) on the experimental_blend branch, I get the following assertion from a debug build of mesa: brw_fs_channel_expressions.cpp:435: virtual ir_visitor_status ir_channel_expressions_visitor::visit_leave(ir_assignment*): Assertion `!"should have been lowered"' failed. I have attached an apitrace of the event which contains the shader code (kind of auto generated by c++, so hard to get otherwise). I couldn't reproduce the problem with the standalone src/glsl/glsl_compiler because some of the shaders wouldn't build because of something that looked like a bug in the standalone. This same assertion happens when I build 11.1.3 from source. All the shaders (as logged using MESA_DEBUG=log) compiled fine with glslang, but I think the crash was during linking so that probably isn't relevant. Using the version 11.1.3 from my distro (without assertions) (Debian Testing), then the shader compiles and creates totally mangled rendering results. This may be unrelated. Even if the shader is totally invalid (it works well for other contributers on a variety of machines), it should probably not be triggering an assertion. Let me know what other information would be helpful.
This ought to be a really simple bug to fix, but I can't seem to reproduce it with your apitrace. I compiled Mesa 11.1.3 in debug mode and your apitrace didn't seem to trigger any assertions...
I actually didn't try to get the assert to happen by replaying. I'll figure out what conditions (env vars possibly) cause it to crash by using the replay function when I get home from work tonight.
Seeing as glAttachShader was the last call in the apitrace output, I assumed that it was the one crashing. After doing a proper gdb session, it was actually in the glLinkShader call that crashes, and it is not recorded in the apitrace, which is why we aren't seeing it in the apitrace that I attached. (I tried and failed to reproduce using replay, for reasons now obvious) I'm just going to attach the three shaders that are being linked (I think, from the trace) to cause the crash. I can't get src/glsl/glsl_compiler to compile the shaders, for a reason that looks unrelated, but if I could maybe the crash could be re-produced that way. If you don't have any better ideas, Kenneth, then I'll write a small GL program that reads in these three shaders and attempts to link them. It will take me a couple of days to find time for that though. Thanks for your help!
Created attachment 123312 [details] Shaders that linked together cause the crash
Thanks! I can reproduce the problem now.
Created attachment 123314 [details] [review] Patch #1
Created attachment 123315 [details] [review] Patch #2
Can you try and apply the two patches I attached (git am 000*) and see if that fixes the assertion? (It might also fix the misrendering...)
Amazing. Fixes both the missing compilation and the rendering issues. This defect can be closed once those are committed. Thank-you very much for your help, Kenneth! Do you know if this is likely to make stable branch?
(Don't close bugs until the patches are upstream)
Duly noted. Thanks.
Fixed in master with the following commits: commit 750c38fad1f19e2403b4960674006c5f932075ad Author: Kenneth Graunke <kenneth@whitecape.org> Date: Wed Apr 27 21:07:07 2016 -0700 glsl: Lower vector_extracts to swizzles after lower_vector_derefs. commit 1cd600dbb975cce616da376a680692afb2da47f9 Author: Kenneth Graunke <kenneth@whitecape.org> Date: Wed Apr 27 20:51:36 2016 -0700 glsl: Convert lower_vec_index_to_swizzle to a rvalue visitor. Both are CC'd to stable, so they should show up in an upcoming point release.
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.