Bug 38357 - [ilk, wine] regression in FEAR
Summary: [ilk, wine] regression in FEAR
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Eric Anholt
QA Contact:
URL: http://www.gamershell.com/download_10...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-15 18:09 UTC by Tobias Jakobi
Modified: 2011-08-31 15:20 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
FEAR screenshot illustrating the artifacts (43.70 KB, image/jpeg)
2011-06-15 18:09 UTC, Tobias Jakobi
Details

Description Tobias Jakobi 2011-06-15 18:09:36 UTC
Created attachment 48016 [details]
FEAR screenshot illustrating the artifacts

I tracked down the regression that already mentioned in bug #34674 (the blueish artifacts).

The commit that introduces the issues is this one:
f147599ef4b0d14c25a7e0d3f9f1c9b0229bb6fc

i965: Remove linear_color for GL_PERSPECTIVE_CORRECTION_HINT
Comment 1 Tobias Jakobi 2011-06-16 06:27:26 UTC
I tracked this down further. Started with commit c095335fa54498ec54e4587b5f84ad6afd8f1857 (intel: Drop doubly irrelevant code in intelReadBuffer), the one right before f147599ef4b0d14c25a7e0d3f9f1c9b0229bb6fc and tested.

The issue appears once I set key->linear_color to 0 in brw_wm.c. Changing code in brw_sf.c doesn't have any effect.

So it seems that ctx->Hint.PerspectiveCorrection is always GL_FASTEST in this context.
Comment 2 Ian Romanick 2011-06-22 13:14:22 UTC
(In reply to comment #1)
> I tracked this down further. Started with commit
> c095335fa54498ec54e4587b5f84ad6afd8f1857 (intel: Drop doubly irrelevant code in
> intelReadBuffer), the one right before f147599ef4b0d14c25a7e0d3f9f1c9b0229bb6fc
> and tested.
> 
> The issue appears once I set key->linear_color to 0 in brw_wm.c. Changing code
> in brw_sf.c doesn't have any effect.
> 
> So it seems that ctx->Hint.PerspectiveCorrection is always GL_FASTEST in this
> context.

It's actually the other way around.  We removed the linear interpolation mode (previously set by GL_FASTEST), so perspective correct interpolation is always used.
Comment 3 Tobias Jakobi 2011-06-22 14:35:00 UTC
(In reply to comment #2)
> It's actually the other way around.  We removed the linear interpolation mode
> (previously set by GL_FASTEST), so perspective correct interpolation is always
> used.
I understand what the patch does, but it's just like a said. Before it seems that the code always takes the GL_FASTEST path. I have no idea if wined3d sets this, but it seems to be the working path.

The artifacts I'm seeing are clearly the effect of perspective-correct interpolation. Previously (before the patch) only linear interpolation was used, which looked correct. So either wined3d needs plain linear interpolation to achieve what it wants to do, or there is an issue in intel driver (related to perspective interp.) that previously didn't surface.
Comment 4 Tobias Jakobi 2011-07-03 06:07:46 UTC
Issue is still present with uptodate mesa git master (7ed1826e2e2a5b5c4840821c92ef7273efe32e24).
Comment 5 Tobias Jakobi 2011-07-30 08:36:55 UTC
Issue is still present with recent mesa git master (120d71a45cfda1edfa8cd6b1732e209eb98b53d8).
Comment 6 Tobias Jakobi 2011-08-31 15:20:25 UTC
Seems to be fixed in latest mesa git master (82fff5f3edfd2f6396a872a12d753b2ab90edd7b).


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.