Bug 43325

(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 ()

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.

Patch posted to the mesa-dev list:

http://lists.freedesktop.org/archives/mesa-dev/2012-February/018566.html

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)

It passes on mesa master branch, but still fails on mesa 8.0 branch.

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.

*** Bug 43324 has been marked as a duplicate of this bug. ***

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.

shall we file a separate bug for float-texture(mipmap.automatic)?

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.