Created attachment 118584 [details] Silhouette of Unigine 4.0 / heaven ship Starting from commit c228514c72cb2fd5fb9e510808e29204fc9e7ae1 Mesa started using its' own drirc instead of /etc/drirc. This causes visual problem with Unigine 4.0 / Heaven test due to missing line <option name=”disable_blend_func_extended” value=”true” /> Visually the scenes show without lighting, just silhouettes of buildings and ship. Screenshot attached.
Hardware this shows up is Haswell and Baytrail, not on Broadwell or Skylake. Exact hardware specifications on request (4 different machines)
Ivy Bridge is also affected. (i7 3632QM)
(In reply to Tomi Sarvela from comment #1) > Hardware this shows up is Haswell and Baytrail, not on Broadwell or Skylake. -> moving to correct component (i965, not i915)
That commit made it use ${sysconfdir}/drirc instead of hardcoding /etc/drirc. If you want it to continue using /etc/drirc, all you need to do is configure Mesa with: ./configure --sysconfdir=/etc (which is what most distro packagers already do) If you don't specify a --sysconfdir, I believe it defaults to /usr/local/etc.
This bug is about Heaven not working on IVB/HSW/BYT *with the Mesa provided drirc* (although that works for GEN8+), not about which drirc Mesa uses. It's also mentioned on Phoronix (where I found this): http://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/841644-intel-enables-tessellation-shader-support-in-open-source-linux-driver/page3 > If you don't specify a --sysconfdir, I believe it defaults to /usr/local/etc. It defaults to "${prefix}/etc" (and prefix defaults to /usr/local).
That makes very little sense. But you're not wrong - Heaven 4.0 somehow works on Broadwell but not Ivybridge. This is, of course, a Unigine bug. IIRC they try to use ARB_blend_func_extended but never specify which fragment shader output is color 0 and which is color 1. So, there's at best a 50/50 chance of getting it right (assuming we try to guess, which we might not - it's illegal after all). Apparently, on Broadwell, we happen to pick the right one, while on Ivybridge, we don't. That's kind of surprising, but with 50/50 odds, sure, why not. They fixed it in Heaven 4.1rc1 over a year and a half ago, but can't be bothered to change the download link on their website to a working version. I've no idea why. Patch sent to mesa-dev to add those workarounds: http://lists.freedesktop.org/archives/mesa-dev/2015-December/103837.html
this should have not made it into the repo for the very same reasons why the kernel doesnt fix broken userspace tools. with this you fixed it for some cards, but regressed on the rest. at most it should have been left as a patch/workaround here in the comments affected users could have applied.
(In reply to Tom Englund from comment #7) > this should have not made it into the repo for the very same reasons why the > kernel doesnt fix broken userspace tools. with this you fixed it for some > cards, but regressed on the rest. at most it should have been left as a > patch/workaround here in the comments affected users could have applied. What regression are you talking about?
(In reply to Kenneth Graunke from comment #8) > (In reply to Tom Englund from comment #7) > > this should have not made it into the repo for the very same reasons why the > > kernel doesnt fix broken userspace tools. with this you fixed it for some > > cards, but regressed on the rest. at most it should have been left as a > > patch/workaround here in the comments affected users could have applied. > > What regression are you talking about? It causes a major performance regression on e.g. nouveau. I assume this is because they do n+1 passes where they would have done n.
(In reply to Ilia Mirkin from comment #9) > It causes a major performance regression on e.g. nouveau. I assume this is > because they do n+1 passes where they would have done n. Thanks, that is constructive feedback. I actually started blacklisting GL_ARB_blend_func_extended for Unigine demos in 2012, because of this very bug. Marek removed this in June 2015 when he dropped support for (the much more broken) Heaven 3.0, re-enabling it. During that three year period, no one had ever mentioned to me that disabling it dropped performance, or expressed any opinion that disabling it was a problem. My patch was simply returning us to the longstanding status quo. I even checked with the AMD developers before proceeding with the patch. Regressing Nouveau is obviously not acceptable. To that end, I've come up with a new drirc workaround that will make Unigine's broken dual color blending work on i965 so we can re-enable it. I hope to send the patches out later tonight, once I've tested them for regressions.
Patch on mesa-dev: http://lists.freedesktop.org/archives/mesa-dev/2016-January/105474.html
I should mention how I've tested it: I verified that Heaven 4.0 rendered black without disable_blend_func_extended on Ivybridge. I then verified that the new workaround fixes the rendering. I ran Heaven 4.0 on Nouveau/NVE0 with the new patch and drirc and it seemed to work fine. I did not performance test it. I ran the patch through Piglit, DEQP, and the GL CTS on most Intel GPUs, but without the new /etc/drirc installed. There weren't any test regressions (as expected, since it shouldn't have any effect).
Nouveau regression should be fixed on master with: commit b3340cd32acf5935891f19833de0cfc500a93e0b Author: Kenneth Graunke <kenneth@whitecape.org> Date: Wed Jan 20 17:33:14 2016 -0800 i965: Implement a drirc workaround for broken dual color blending.
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.