Bug 79685

Summary:	Varying passed from gs->fs corrupted if not first similar draw.
Product:	Mesa	Reporter:	David Gow <david>
Component:	Drivers/DRI/i965	Assignee:	Ian Romanick <idr>
Status:	RESOLVED FIXED	QA Contact:	Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity:	normal
Priority:	medium	CC:	itoral
Version:	10.1
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

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.