Bug 66292 - [SNB/IVB/HSW Bisected]Ogles3conform GL3Tests_depth24_depth24_basic.test fail
Summary: [SNB/IVB/HSW Bisected]Ogles3conform GL3Tests_depth24_depth24_basic.test fail
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: high major
Assignee: Ian Romanick
QA Contact:
Depends on:
Blocks: 67224
  Show dependency treegraph
Reported: 2013-06-28 02:51 UTC by lu hua
Modified: 2013-08-19 02:02 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

output (9.65 KB, text/plain)
2013-06-28 02:51 UTC, lu hua
patch to fix/workaround the issue (1.26 KB, text/plain)
2013-07-31 06:15 UTC, Tapani Pälli

Description lu hua 2013-06-28 02:51:35 UTC
Created attachment 81599 [details]

System Environment:
Arch:           x86_64
Platform:       Haswell/Ivybridge
Libdrm:		(master)libdrm-2.4.45-10-gfbd106ad76b0ee33814f6a5b94efaa0b067ec2af
Mesa:		(master)15085b477b092ba4315d13b96112a8d714de8e27
Cairo:		(master)4d9439132de85c0f0f4d5b5a474ea7164910251e
Libva:		(staging)4b674a906140156793bf6eba441738bafd45749b
Kernel:	(drm-intel-nightly) 8fd4841995c408bab64400d2b00b64cde6bbd650

Bug detailed description:
It fails on haswell and ivybridge withe mesa master branch.It works well on 9.1 branch.
GL3Tests_depth24_depth24_precision.test and L3Tests_rgb8_rgba8_rgb8_rgba8_rgb.test also fail.
Bisect shows:the first bad commit could be any of 4563dfe23a300f0fc1652a609f5ad9e9a755fb99,dd0b99b0beccf93cd53f42e05bc834c0fed57edf ,15436adab0ae2dea5d62567326f1f3969939. Built fail with the 3 commits. I can't revert them.I can't bisect more.

Reproduce steps:
1. xinit
2. ./GTF -width=64 -height=64 -run=GL3Tests/depth24/depth24_basic.test
Comment 1 lu hua 2013-07-17 01:26:36 UTC
It also happens on mesa 9.1 branch.
Bisect shows:c170c901d0f5384e5ab8b79b827663fa28439b0b is the first bad commit.
commit c170c901d0f5384e5ab8b79b827663fa28439b0b
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Fri Jun 7 17:05:22 2013 -0700

    glsl: Move all var decls to the front of the IR list in reverse order

    This has the (intended!) side effect that vertex shader inputs and
    fragment shader outputs will appear in the IR in the same order that
    they appeared in the shader code.  This results in the locations being
    assigned in the declared order.  Many (arguably buggy) applications
    depend on this behavior, and it matches what nearly all other drivers

    Fixes the (new) piglit test attrib-assignments.

    NOTE: This is a candidate for stable release branches (and requires the
    previous commit to prevent a regression in OpenGL ES 2.0 conformance
    test stencil_plane_operation).

    Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
    Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Comment 2 lu hua 2013-07-17 01:27:51 UTC
It also happens on sandybridge.
Comment 3 Tapani Pälli 2013-07-29 12:33:06 UTC
I can reproduce this, I don't quite understand why the test fails though as it uses glGetAttribLocation to fetch locations so it should not depend on particular location. Maybe commit c170c901d0f5384e5ab8b79b827663fa28439b0b should sort only the variables coming from user and ignore language variables like gl_Position or gl_DepthRange. With re-ordering the variables are in same order declared but in the bottom of the ir list. I will investigate more to gain better understanding.
Comment 4 Tapani Pälli 2013-07-31 06:15:59 UTC
Created attachment 83343 [details]
patch to fix/workaround the issue

Attaching a patch that fixes the issue, when linking it marks locations used by builtin variables to used_locations mask. However, I'm not sure if this is the right cure, Ian please comment.
Comment 5 Tapani Pälli 2013-07-31 07:31:42 UTC
like I was afraid I think the patch actually just hides the issue as location 0 gets unutilized this way, location 0 seems to be the problem here, 'used_locations |= (1 << 0)' seems enough of a workaround. Will try to figure out why.
Comment 6 Tapani Pälli 2013-07-31 09:57:28 UTC
Robert's patch in bug #55503 makes these tests work.
Comment 7 Ian Romanick 2013-08-07 19:30:06 UTC
I have posted a somewhat different patch to the mesa-dev mailing list for review:

Comment 8 Ian Romanick 2013-08-15 22:01:40 UTC
commit 41eef83cc030e7087b79b0070d00fbc56538fb81
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Wed Aug 7 11:15:41 2013 -0700

    mesa/vbo: Fix handling of attribute 0 in non-compatibilty contexts
    It is only in OpenGL compatibility-style contexts where generic
    attribute 0 and GL_VERTEX_ARRAY have a bizzare, aliasing relationship.
    Moreover, it is only in OpenGL compatibility-style contexts and OpenGL
    ES 1.x where one of these attributes provokes the vertex.  In all other
    APIs each implicit call to glArrayElement provokes a vertex regardless
    of which attributes are enabled.
    Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
    Reviewed-by: Robert Bragg <robert@sixbynine.org>
    Cc: "9.0 9.1 9.2" <mesa-stable@lists.freedesktop.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55503
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66292
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67548
Comment 9 lu hua 2013-08-19 02:02:05 UTC

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.