Bug 43325 - [bisected SNB]oglc float-texture(mipmap.manual) segfaults
Summary: [bisected SNB]oglc float-texture(mipmap.manual) segfaults
Status: VERIFIED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: All Linux (All)
: high major
Assignee: Ian Romanick
QA Contact:
URL:
Whiteboard:
Keywords:
: 43324 (view as bug list)
Depends on:
Blocks: 42993
  Show dependency treegraph
 
Reported: 2011-11-29 01:43 UTC by fangxun
Modified: 2012-10-23 06:34 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
float-texture(mipmap.automatic) output (22.14 KB, text/plain)
2012-02-08 22:40 UTC, fangxun
Details

Description fangxun 2011-11-29 01:43:23 UTC
System Environment:
--------------------------
Arch:           i386
Platform:       huronriver
Libdrm:         (master)2.4.27-2-gca4971292cf99e0063416cd1c3467af94637bf2b
Mesa:           (master)d4fcf67a3ac78c29448000486dadc2b4b1b2a56d
Xserver:      
(master)xorg-server-1.11.99.1-43-gb2015a2c01711646bb7ae23d684abee0cd55d4d0
Xf86_video_intel: (master)2.17.0-26-g16f5e224dcfd97012b38ee1af6c72dbe3c0f3304
Kernel:  (drm-intel-next)9a10f401a401ca69c6537641c8fc0d6b57b5aee8


Bug detailed description:
------------------------- 
It segfaults on Sandybridge. Oglc wrap3d(advanced.floatrg) fails due to the sam e bisected bad commit.
Bisect shows 1e42568bf304e9b3bae9fef8ad8febd25e1ac29f is the first bad commit.
commit 1e42568bf304e9b3bae9fef8ad8febd25e1ac29f
Author:     Eric Anholt <eric@anholt.net>
AuthorDate: Tue Nov 15 16:26:29 2011 -0800
Commit:     Eric Anholt <eric@anholt.net>
CommitDate: Tue Nov 22 13:58:38 2011 -0800

    i965: Add support for half-float formats.

    Now that all the rest of the driver is driven off of the surface
    formats table, all we really need to do is add the mapping from
    MESA_FORMAT to BRW_SURFACEFORMAT.  However, we also add format
    override for I16/L16 render targets at the same time, so that existing
    users of I16 that were getting promoted to I32 and then getting the
    I32->R32 override still get FBO support.

    Fixes failures in piglit gl-3.0-required-sized-texture-formats, and
    will prevent regressions in ARB_texture_float on gen4 when moving to
    fully table-driven texture format setup.

    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>


Reproduce steps:
----------------
1. start X
2. ./oglconform -z -s -suite all -v 2 -D 115 -test float-texture mipmap.manual
Comment 1 fangxun 2011-11-29 02:35:54 UTC
(gdb) bt
#0  0xb7cdb8fa in do_row_3D (datatype=5131, comps=2, border=0, srcWidth=128, srcHeight=128, srcDepth=128, srcPtr=0xaa88de0, srcRowStride=512, dstWidth=64, dstHeight=64,
    dstDepth=64, dstPtr=0xa9850b0, dstRowStride=512) at main/mipmap.c:1008
#1  make_3d_mipmap (datatype=5131, comps=2, border=0, srcWidth=128, srcHeight=128, srcDepth=128, srcPtr=0xaa88de0, srcRowStride=512, dstWidth=64, dstHeight=64, dstDepth=64,
    dstPtr=0xa9850b0, dstRowStride=512) at main/mipmap.c:1600
#2  0xb7cddb56 in generate_mipmap_uncompressed (ctx=0x9b72928, target=32879, texObj=0xa983bb0) at main/mipmap.c:1894
#3  _mesa_generate_mipmap (ctx=0x9b72928, target=32879, texObj=0xa983bb0) at main/mipmap.c:2085
#4  0xb7c5796d in _mesa_meta_GenerateMipmap (ctx=0x9b72928, target=32879, texObj=0xa983bb0) at drivers/common/meta.c:2824
#5  0xb7b4f8b4 in _mesa_GenerateMipmapEXT (target=32879) at main/fbobject.c:2595
#6  0x081ef7e0 in float_textures::subcases::TestMipmapManual() ()
#7  0x081f120b in float_texturesExec(testParameters*) ()
#8  0x08cea348 in callFunctionHandleExceptionsInner(long (*)(testParameters*), testParameters*, char*) ()
#9  0x08cea497 in callFunctionHandleExceptions(long (*)(testParameters*), testParameters*) ()
#10 0x08ce8f49 in DriverExec(long (*)(testParameters*), testParameters*) ()
#11 0x08ccee99 in Driver(std::vector<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > const&, std::vector<driverRec*, std::allocator<driverRec*> > const&, std::vector<boost::shared_ptr<PrePostTestAction>, std::allocator<boost::shared_ptr<PrePostTestAction> > > const&, std::vector<boost::shared_ptr<PrePostTestcaseAction>, std::allocator<boost::shared_ptr<PrePostTestcaseAction> > > const&) ()
#12 0x08ccf2ae in (anonymous namespace)::MyMessagePump::idle() ()
#13 0x08ca26fa in MessagePump::process_messages() ()
#14 0x08ccfc96 in ExecutionManager::execute_schedules() ()
#15 0x08c5f7ab in tkShellExecute(std::vector<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > const&, std::vector<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > const&) ()
#16 0x08c686c2 in main ()
Comment 2 Paul Berry 2012-01-17 15:18:11 UTC
I reproduced the failure on my machine and got a little bit more information.

The failing test generates textures with various texture types and internal formats, calls glGenerateMipmapEXT() to cause a mipmap to be generated, and then checks that all mipmap levels have been generated correctly by using the texture for drawing.

The failure only happens when testing GL_TEXTURE_3D with one of the following internal formats:

GL_LUMINANCE_ALPHA16F_ARB
GL_R16F
GL_INTENSITY16F_ARB
GL_RG16F
GL_LUMINANCE16F_ARB

I checked whether Brian Paul's "renderbuffer-cleanups-v2" branch fixes any of these failures.  It doesn't.

I'm not familiar enough with the Mesa mipmap code to fix this bug.  In the long run I would like to make a Piglit test that reproduces it, but that will take some time since at the moment all of our existing mipmap tests are 2D-only.  So I'm going to work on some other bugs first.
Comment 3 Ian Romanick 2012-02-01 13:26:51 UTC
Patch posted to the mesa-dev list:

http://lists.freedesktop.org/archives/mesa-dev/2012-February/018566.html
Comment 4 Ian Romanick 2012-02-02 11:01:12 UTC
Fixed on the 8.0 branch by:

commit 4635e26db23dae60b7586995eb3cf27cb9841443
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Wed Feb 1 14:19:35 2012 -0700

    mesa: Fix copy-and-paste bug in do_row_3D
    
    Several of the half-float cases used 4 as the texel size when it
    should have been some smaller value.
    
    NOTE: This is a candidate for the 8.0 branch.
    
    Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
    Reviewed-by: Brian Paul <brianp@vmware.com>
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43324
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43325
    (cherry picked from commit 5c341b7df3c1058d586629394e53e9e26ae2cc01)
Comment 5 fangxun 2012-02-08 01:55:35 UTC
It passes on mesa master branch, but still fails on mesa 8.0 branch.
Comment 6 Ian Romanick 2012-02-08 11:58:39 UTC
I'm not able to reproduce this failure on the 8.0 branch.  Please attach output from the test.  Please also be sure that you are building with --enable-texture-float.
Comment 7 Ian Romanick 2012-02-08 11:59:29 UTC
*** Bug 43324 has been marked as a duplicate of this bug. ***
Comment 8 fangxun 2012-02-08 22:40:36 UTC
Created attachment 56788 [details]
float-texture(mipmap.automatic) output

With --enable-texture-float, float-texture(mipmap.manual) passes on 8.0 branch. Oglc float-texture(mipmap.automatic) still fails on mesa master and 8.0 branch.
Comment 9 Gordon Jin 2012-03-31 18:03:13 UTC
shall we file a separate bug for float-texture(mipmap.automatic)?
Comment 10 fangxun 2012-03-31 22:03:08 UTC
oglc float-texture(mipmap.automatic) was fixed on mesa master by below commit. The fix commit is not cherry-picked to 8.0 branch, so it still fails on mesa 8.0. I add this case to bug 44961 for tracking. Closing the bug.
commit e2dce7f7ee3e7da9cbb0bb33307ecd79e824426d
Author: Eric Anholt <eric@anholt.net>
Date:   Fri Feb 10 12:54:25 2012 -0800

    intel: Fix rendering from textures after RenderTexture().

    There's a serious trap for drivers: RenderTexture() does not indicate
    that the texture is currently bound to the draw buffer, despite
    FinishRenderTexture() signaling that the texture is just now being
    unbound from the draw buffer.

    We were acting as if RenderTexture() *was* the start of rendering and
    that we could make texturing incoherent with the current contents of
    the renderbuffer.  This caused intel oglconform sRGB
    Mipmap.1D_textures to fail, because we got a call to TexImage() and
    thus RenderTexture() on a texture bound to a framebuffer that wasn't
    the draw buffer, so we skipped validating the new image into the
    texture object used for rendering.

    We can't (easily) make RenderTexture() indicate the start of drawing,
    because both our driver and gallium are using it as the moment to set
    up the renderbuffer wrapper used for things like MapRenderbuffer().
    Instead, postpone the setup of the workaround render target miptree
    until update_renderbuffer time, so that we no longer need to skip
    validation of miptrees used as render targets.  As a bonus, this
    should make GL_NV_texture_barrier possible.

    (This also fixes a regression in the gen4 small-mipmap rendering since
    3b38b33c1648b07e75dc4d8340758171e109c598, which switched
    set_draw_offset from image->mt to irb->mt but didn't move the irb->mt
    replacement up before set_draw_offset).

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44961
    NOTE: This is a candidate for the 8.0 branch.


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.