Bug 71741 - GL_ARB_ES3_compatibility and std140 arrays
Summary: GL_ARB_ES3_compatibility and std140 arrays
Status: RESOLVED NOTOURBUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 9.1
Hardware: x86 (IA32) Linux (All)
: medium major
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-18 14:31 UTC by Stanislav Vorobiov
Modified: 2014-04-08 22:55 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
std140 array bug (7.39 KB, text/plain)
2013-11-18 14:31 UTC, Stanislav Vorobiov
Details

Description Stanislav Vorobiov 2013-11-18 14:31:45 UTC
Created attachment 89409 [details]
std140 array bug

It appears that mesa 9.1.7 incorrectly handles arrays inside uniform blocks with std140 layout when GL_ARB_ES3_compatibility is used. I've attached a sample program, build it with:

gcc std140_bug.c -o std140_bug -lX11 -lGL -lm

The program draws a triangle, rotation angle is taken from a uniform buffer in vertex shader like this:

float angle = rotations[1];

This should access 2'nd array element, but instead it accesses 5'th element, as a result triangle is rotated by 85 degrees (appears narrow) when it should be rotated by 0 degrees (appear wide)

glxinfo:
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Desktop x86/MMX/SSE2
OpenGL version string: 3.0 Mesa 9.1.7
OpenGL shading language version string: 1.30
uname -a:
Linux xxx 3.11.0-13-generic #20~precise2-Ubuntu SMP Thu Oct 24 21:07:45 UTC 2013 i686 i686 i386 GNU/Linux
Comment 1 Ian Romanick 2013-11-18 16:11:29 UTC
I am able to reproduce this on current 10.0 branch.  It appears that the float array is being packed as a vec4 array.  I believe this is actually correct.  By rule #4 of the std140 packing:

      (4) If the member is an array of scalars or vectors, the base alignment
          and array stride are set to match the base alignment of a single
          array element, according to rules (1), (2), and (3), and rounded up
          to the base alignment of a vec4. The array may have padding at the
          end; the base offset of the member following the array is rounded up
          to the next multiple of the base alignment.

The important bit is "rounded up to the base alignment of a vec4."

Have you tried this on other OpenGL implementations?
Comment 2 Stanislav Vorobiov 2013-11-18 17:00:18 UTC
>Have you tried this on other OpenGL implementations?
Mali has 2 samples in their SDK - "instancing" and "instanced tesselation" that use arrays of floats and also treat elements as float aligned, it's here:
http://malideveloper.arm.com/develop-for-mali/sdk/opengl-es-sdk-for-linux/
Comment 3 Kenneth Graunke 2014-04-07 15:05:41 UTC
As is, the program fails to compile shaders on both Mesa and nVidia's binary driver - you need to add "precision highp float;\n" to the fragment shader.

With that change, Mesa (Haswell, 10.2-devel) and nVidia (GTX 760, 334.21) have the same behavior - a narrow and tall triangle pointing upwards.
Comment 4 Anuj Phogat 2014-04-08 18:08:19 UTC
My AMD system (Radeon HD 6480G, 9.012) doesn't support GL_ARB_ES3_compatibility.
So, failed to compile the shaders. After removing "#version 300 es" from
shaders, I get an output matching mesa behavior.
Comment 5 Stanislav Vorobiov 2014-04-08 20:10:59 UTC
Yes, I agree that Mali has bad behavior here, they misinterpreted the standard. So this bug can be closed I guess


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.