Bug 79685 - Varying passed from gs->fs corrupted if not first similar draw.
Summary: Varying passed from gs->fs corrupted if not first similar draw.
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 10.1
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-05 15:12 UTC by David Gow
Modified: 2015-03-11 09:09 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description David Gow 2014-06-05 15:12:47 UTC
This is a strange one.

I've got a bunch of simple objects being rendered (rectangles and ellipses), using different gs+fs, but the same vs. One of the gs+fs pairs passes a vec2 varying from the gs->fs. If this object is the first (nonempty) drawcall in the frame, it renders correctly as a circle (the varying being "texture coordinates" as it were). If another gs+fs combination runs first, the varying is not passed through correctly.

Example apitrace: http://davidgow.net/stuff/gs-fs-var.trace.bz2
- At call #180, we should see an ellipse, but see a rectangle.
  http://davidgow.net/stuff/gs-fs-var-bad.png
- If we change the glUseProgram in call #175 to use program 13, we see the ellipse at call #180.
  http://davidgow.net/stuff/gs-fs-var-good.png

The source for program 13 is located here: http://davidgow.net/stuff/gs-fs-var.glsldump

This code correctly displays the ellipse on both the nvidia and fglrx drivers, but fails on both Mesa 10.1 (Ubuntu 14.04) and Mesa git (2211696-) IVB.

Am I doing anything obviously wrong?

Thanks,
— David
Comment 1 Iago Toral 2015-03-10 11:32:04 UTC
I think this got fixed at some point, at least with current master I get an ellipse when replaying the attached  apitrace.
Comment 2 Iago Toral 2015-03-10 11:47:23 UTC
(In reply to Iago Toral from comment #1)
> I think this got fixed at some point, at least with current master I get an
> ellipse when replaying the attached  apitrace.

And FWIW, I can confirm that the problem existed before, since I can reproduce it with mesa 10.3.2 from Ubuntu.
Comment 3 Ian Romanick 2015-03-11 03:02:55 UTC
Any chance one of you gentlemen could bisect this, and we'll close it?
Comment 4 Iago Toral 2015-03-11 09:09:40 UTC
(In reply to Ian Romanick from comment #3)
> Any chance one of you gentlemen could bisect this, and we'll close it?

Sure, this got fixed by:

commit b51ff50a767cc78d678ed3d2c25995f5c4194fea
Author: Chris Forbes <chrisf@ijw.co.nz>
Date:   Sat Feb 28 19:57:20 2015 +1300

    i965/gs: Check newly-generated GS-out VUE map against correct stage

    Previously, we compared our new GS-out VUE map to the existing *VS*-out
    VUE map, which is bogus.

    This would mostly manifest as redundant dirty flagging where the GS is
    in use but the VS and GS output layouts differ; but there is a scary
    case where we would fail to flag a GS-out layout change if it happened
    to match the VS-out layout.

    Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
    Cc: "10.5, 10.4" <mesa-stable@lists.freedesktop.org>
    Reviewed-by: Matt Turner <mattst88@gmail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88885


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.