|Summary:||[SNB/IVB/HSW Bisected]Ogles3conform GL3Tests_depth24_depth24_basic.test fail|
|Product:||Mesa||Reporter:||lu hua <huax.lu>|
|Component:||Drivers/DRI/i965||Assignee:||Ian Romanick <idr>|
|Status:||VERIFIED FIXED||QA Contact:|
|i915 platform:||i915 features:|
|Bug Depends on:|
patch to fix/workaround the issue
Description lu hua 2013-06-28 02:51:35 UTC
Created attachment 81599 [details] output System Environment: -------------------------- Arch: x86_64 Platform: Haswell/Ivybridge Libdrm: (master)libdrm-2.4.45-10-gfbd106ad76b0ee33814f6a5b94efaa0b067ec2af Mesa: (master)15085b477b092ba4315d13b96112a8d714de8e27 Xserver:(master)xorg-server-220.127.116.11-130-g77e51d5bbb97eb5c9d9dbff9a7c44d7e53620e68 Xf86_video_intel:(master)2.21.10-33-gd7be3df2fe632bbc8e4f09709cf3cf7a5ef61015 Cairo: (master)4d9439132de85c0f0f4d5b5a474ea7164910251e Libva: (staging)4b674a906140156793bf6eba441738bafd45749b Libva_intel_driver:(staging)bb24c8a81e512d19aad0359d81f7247e6f20cc29 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 <email@example.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 do. 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 <firstname.lastname@example.org> Reviewed-by: Chad Versace <email@example.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 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: http://lists.freedesktop.org/archives/mesa-dev/2013-August/042881.html
Comment 8 Ian Romanick 2013-08-15 22:01:40 UTC
commit 41eef83cc030e7087b79b0070d00fbc56538fb81 Author: Ian Romanick <firstname.lastname@example.org> 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 <email@example.com> Reviewed-by: Robert Bragg <firstname.lastname@example.org> Cc: "9.0 9.1 9.2" <email@example.com> 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