Bug 64662 - [SNB 9.1 Bisected]Ogles2conform GL2ExtensionTests/depth_texture_cube_map/depth_texture_cube_map.test fail
Summary: [SNB 9.1 Bisected]Ogles2conform GL2ExtensionTests/depth_texture_cube_map/dept...
Status: VERIFIED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 9.1
Hardware: All Linux (All)
: high major
Assignee: Paul Berry
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-16 06:53 UTC by lu hua
Modified: 2013-05-17 01:23 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
output (9.63 KB, text/plain)
2013-05-16 06:53 UTC, lu hua
Details

Description lu hua 2013-05-16 06:53:53 UTC
Created attachment 79381 [details]
output

System Environment:
--------------------------
Arch:             i386
Platform:         Sandybridge
Libdrm:		(master)2.4.44-9-g96e90aabc4c0238de2f2d245899f991a3b996587
Mesa:(9.1)c3eb301a3a09f4b1b471afdbd16a4f986702f194
Xserver:(server-1.13-branch)xorg-server-1.13.4
Xf86_video_intel:(master)2.21.6-41-gf57a65c35268f215c17f1a02b3af50a6678ce3c1
Cairo:	(master)631bf299256e11a17511977f357e0353fb5615f7
Libva:(master)32e44bcf45ee0f4a345ccaedda1d45079e8186ed
Libva_intel_driver:(master)31caada2967b94705d78ab7f6d07965ad7f13d42
Kernel:	(drm-intel-fixes) e6c6992522d3f74341f032bda2c76266057cc53b

Bug detailed description:
-------------------------
It fails on sandybridge with mesa 9.1 branch. It has another bug on mesa master branch Bug 64659.

Bisect shows:496996010561463bf0f2e2a7632978c548065b98 is the first bad commit.
commit 496996010561463bf0f2e2a7632978c548065b98
Author:     Chad Versace <chad.versace@linux.intel.com>
AuthorDate: Fri Apr 5 15:18:00 2013 -0700
Commit:     Paul Berry <stereotype441@gmail.com>
CommitDate: Tue May 14 11:24:49 2013 -0700

    intel: Allocate hiz in intel_renderbuffer_move_to_temp()

    When moving the renderbuffer to a new miptree, we neglected to allocate
    the hiz buffer for the new miptree. Oops.

    Fixes all Piglit depthstencil-render-miplevels tests from crash to pass on
    Sandybridge.

    Note: This is a candidate for the 9.1 branch.
    Reviewed-by: Eric Anholt <eric@anholt.net>
    Reviewed-by: Paul Berry <stereotype441@gmail.com>
    Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
    (cherry picked from commit aa391976dfa12479185d9eeed1f2a0b4dce6c49b)

Reproduce steps:
----------------
1. xinit
2. ./GTF -width=64 -height=64 -run=GL2ExtensionTests/depth_texture_cube_map/depth_texture_cube_map.test
Comment 1 Ian Romanick 2013-05-16 16:23:18 UTC
Chad and Paul,

Can one of you either fix this or revert in the next 24 hours?  Thanks.
Comment 2 Paul Berry 2013-05-16 17:44:29 UTC
(In reply to comment #1)
> Chad and Paul,
> 
> Can one of you either fix this or revert in the next 24 hours?  Thanks.

I've confirmed that I can reproduce the bug on Sandy Bridge.  I'll investigate and update the bug as soon as I know more.
Comment 3 Chad Versace 2013-05-16 17:47:52 UTC
I suspect that this patch depends on one the patches in my Haswell HiZ series (d5f7aebac..e4484a030) on master, none of which were cherry-picked.
Comment 4 Paul Berry 2013-05-16 21:40:28 UTC
Found the problem.

When intel_finalize_mipmap_tree() calls intel_miptree_copy_teximage() to reassemble a depth miptree that has been broken apart into pieces (to deal with misalignment of levels/layers within the miptree), it just copies the depth data, not the HiZ data.  This is reasonable, since the alignment restrictions of HiZ are a large part of the reason why the miptree had to be broken apart in the first place.  However, in order for the depth copy to be sufficient, we need to do a depth resolve first, to make sure any deferred depth writes that are in the HiZ buffer get performed.  Currently we don't have any code to do the necessary depth resolve.

The reason the bug shows up on Sandy Bridge but not Ivy Bridge is that Ivy Bridge has a different QPitch formula (as a result of supporting a slightly larger maximum texture size), and coincidentally for the buffer size used in the test, only Sandy Bridge's QPitch formula results in misaligned layers in the texture.

I have a small patch that fixes the bug (http://lists.freedesktop.org/archives/mesa-dev/2013-May/039449.html).  It's already been reviewed by Chad.  I'll do some more testing this afternoon, and unless I uncover a problem with it, I'll commit it to the master branch and cherry-pick it back to 9.1 by the end of the day.
Comment 5 Paul Berry 2013-05-17 01:11:41 UTC
Fixed by commit cbe0e50247c909a7d34f71d9a1a4852b6c3af472
Author: Paul Berry <stereotype441@gmail.com>
Date:   Thu May 16 14:12:15 2013 -0700

    intel: Do a depth resolve before copying images between miptrees.
    
    When intel_finalize_mipmap_tree() calls intel_miptree_copy_teximage()
    to reassemble a depth miptree that has been broken apart into pieces
    (to deal with misalignment of levels/layers within the miptree), it
    just copies the depth data, not the HiZ data.  This is reasonable,
    since the alignment restrictions of HiZ are a large part of the reason
    why the miptree had to be broken apart in the first place.  However,
    in order for the depth copy to be sufficient, we need to do a depth
    resolve first, to make sure any deferred depth writes that are in the
    HiZ buffer get performed.
    
    Fixes https://bugs.freedesktop.org/show_bug.cgi?id=64662 and
    https://bugs.freedesktop.org/show_bug.cgi?id=64659.
    
    NOTE: This is a candidate for stable release branches.
    
    Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
    (cherry picked from commit 46ea8041074df79561f9771e2ecf198f2cbd088f)
Comment 6 lu hua 2013-05-17 01:23:15 UTC
Verified.Fixed by commit cbe0e50247c909a7d34f71d9a1a4852b6c3af472.
commit cbe0e50247c909a7d34f71d9a1a4852b6c3af472
Author: Paul Berry <stereotype441@gmail.com>
Date:   Thu May 16 14:12:15 2013 -0700

    intel: Do a depth resolve before copying images between miptrees.


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.