Bug 92233 - Unigine Heaven 4.0 silhuette run
Summary: Unigine Heaven 4.0 silhuette run
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Kenneth Graunke
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-02 06:44 UTC by Tomi Sarvela
Modified: 2016-01-22 22:29 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Silhouette of Unigine 4.0 / heaven ship (1.09 MB, image/png)
2015-10-02 06:44 UTC, Tomi Sarvela
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tomi Sarvela 2015-10-02 06:44:56 UTC
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.
Comment 1 Tomi Sarvela 2015-10-02 06:47:33 UTC
Hardware this shows up is Haswell and Baytrail, not on Broadwell or Skylake.
Exact hardware specifications on request (4 different machines)
Comment 2 Christoph Haag 2015-12-26 22:14:23 UTC
Ivy Bridge is also affected. (i7 3632QM)
Comment 3 Eero Tamminen 2015-12-28 08:34:21 UTC
(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)
Comment 4 Kenneth Graunke 2015-12-28 09:16:32 UTC
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.
Comment 5 Eero Tamminen 2015-12-28 10:41:24 UTC
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).
Comment 6 Kenneth Graunke 2015-12-28 22:24:23 UTC
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
Comment 7 Tom Englund 2016-01-09 18:10:55 UTC
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.
Comment 8 Kenneth Graunke 2016-01-09 23:18:51 UTC
(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?
Comment 9 Ilia Mirkin 2016-01-20 15:29:29 UTC
(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.
Comment 10 Kenneth Graunke 2016-01-21 04:03:30 UTC
(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.
Comment 11 Kenneth Graunke 2016-01-21 04:35:57 UTC
Patch on mesa-dev:
http://lists.freedesktop.org/archives/mesa-dev/2016-January/105474.html
Comment 12 Kenneth Graunke 2016-01-21 04:40:04 UTC
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).
Comment 13 Kenneth Graunke 2016-01-22 22:29:59 UTC
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.


bug/show.html.tmpl processed on Jan 18, 2017 at 01:48:00.
(provided by the Example extension).