Bug 88885 - Transform feedback uses incorrect interleaving if a previous draw did not write gl_Position
Summary: Transform feedback uses incorrect interleaving if a previous draw did not wri...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Carl Worth
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-30 23:45 UTC by James Legg
Modified: 2015-03-24 06:58 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Reproducer (3.89 KB, text/plain)
2015-01-30 23:45 UTC, James Legg
Details

Description James Legg 2015-01-30 23:45:23 UTC
Created attachment 112993 [details]
Reproducer

After a draw with a shader program that has transform feedback varyings set, and has a geometry shader that does not write to gl_Position, subsequent uses of transform feedback with interleaved transform feedback attributes can out write attributes in the wrong order, or with some missing. In every case of this I've seen, the space used for each vertex's attributes was correct but the offset within the vertex's data is wrong for some attributes.

The attached program demonstrates the problem. The second draw call writes three transform feedback attributes. They are a float, a vec3, and another float. When the transform feedback buffer is read back, the last component of the vec3 has the value that should have been written to the second float, and the second float ends up with 0. The output is in the correct order if the first draw call is removed, if the first draw's geometry shader is changed to write to gl_Position, or if the geometry shader for the second draw writes only compile time constants to the transform feedback attributes.

I this bug is consistently reproducible for me. I am using Intel Haswell graphics, x86_64 architecture, with Fedora 21 and mesa git b930ef1ce8222156464cfd1e744c9598ace5efbb master branch. The Fedora 21 mesa 10.4.1 and 10.4.2 packages also reproduce the bug.
Comment 1 Felix Schwarz 2015-02-01 21:05:09 UTC
This works for me on r600g but I see a crash in your reproducer on Intel (gen4) using both mesa 10.4.2. Problem might be specific to Intel.
Comment 2 Chris Forbes 2015-03-05 08:27:04 UTC
James,

This should be fixed in master now by:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=b51ff50a767cc78d678ed3d2c25995f5c4194fea

- Chris
Comment 3 Tapani Pälli 2015-03-24 06:58:37 UTC
Thanks Chris! This commit has fixed also rendering issues with some of the heavyweight UE4 demos where we had 'yellow tint' colors.


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.