Created attachment 43055 [details]
Small => Ok

Created attachment 43056 [details]
Large => Ok

I'm guessing the black lines on the bottom of the picture are also a bug I think.

1) When I disable "Enabled texture tiling" in driconf, the problem goes away. So it looks it's related to tiling functionality.

2) I also tried disabling 3d acceleration in driconf, but that gave a totally different problem. See attached screenshot.

So it looks like we may have two different issues. Should I file a new bug for mesa software?

Created attachment 43057 [details]
Software => Dark texture

When I turned off 3d acceleration in driconf, this was the result.

(sorry for all these comments)

Some further testing:

The problem doesn't show in neither software or 3d accelerated (including texture tiling enabled) when the texture is a power-of-two. 

When the texture is a non-power-of-two the above mentioned problems appear. 

I'm testing for 'GL_ARB_texture_non_power_of_two' which is advertised by mesa and according to the standard should allow for mip-mapping (as far as I know).

Do you have any sample code to reproduce the problem?  We have many testcases for mipmap generation in piglit (http://cgit.freedesktop.org/piglit/tree/tests/texturing/gen-teximage.c, http://cgit.freedesktop.org/piglit/tree/tests/fbo/fbo-generatemipmap-formats.c for example), and it would be nice to see what's different in your code that produce this problem.

Here's the code I use. I currently disable the npot textures.
http://code.google.com/p/gogglesmm/source/browse/src/GMImageView.cpp#57

Since it has been a couple of months, I retested it again with pretty much the same results.

To recap: 

npot, no accel => darkened/lightened texture 
npot, accel => ok
npot, accel, texture tiling => blurry/shifted texture 

pot, no accel => malformed texture (see attached screenshot)
pot, accel => ok
pot, accel, texture tiling => ok

Current Versions on my Arch Linux install:
mesa 7.10.99.git20110612-1
intel-dri 7.10.99.git20110612-1
xf86-video-intel 2.15.0-2

Created attachment 47966 [details]
3d accel disabled, pot texture + mipmapping

I was thinking of something standalone that reproduced the problem, or instructions for how to reproduce it at least.  One option would be to use apitrace to capture a trace so I could replay it without requiring a working build of your app.

I'm also not sure what hardware you're using (http://intellinuxgraphics.org/how_to_report_bug.html)

(In reply to comment #10)
> I was thinking of something standalone that reproduced the problem, or
> instructions for how to reproduce it at least.  One option would be to use
> apitrace to capture a trace so I could replay it without requiring a working
> build of your app.
> 
> I'm also not sure what hardware you're using
> (http://intellinuxgraphics.org/how_to_report_bug.html)

Ok, I'll try out apitrace and will post the results.

-- chipset: 965GM
-- system architecture: x86_64
-- versions:
xorg-server 1.10.3-2
mesa 7.11rc1-4
libdrm 2.4.26-1
xf86-video-intel 2.15.0-2
-- kernel version: 2.6.39-ARCH
-- Linux distribution: Arch Linux
-- Machine or mobo model: Toshiba U305 
-- Display connector: LVDS

Created attachment 49307 [details]
apitrace output

Here I resize the texture a couple of times. For example frame 4 and 7 appear blurred. Let me know if this helps.

Yes, that's hugely helpful...thanks!

I just sent a patch to mesa-dev that I believe fixes the issue.  The subject is "i965: Check actual tile offsets in Gen4 miptree workaround."

Pending review, I'll commit it soon.

Should be fixed in Mesa master by the following commit:

commit 15c0bc5eefc89bec537e412c02965f201fb1c011
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Mon Jul 25 17:06:13 2011 -0700

    i965: Check actual tile offsets in Gen4 miptree workaround.
    
    The purpose of the (irb->draw_offset & 4095) != 0 check was to ensure
    that we don't have XYy offsets into a tile, since Gen4 hardware doesn't
    support that.  However, it's insufficient: there are cases where
    draw_offset & 4095 is 0 but we still have a Y-offset.  This leads to an
    assertion failure in brw_update_renderbuffer_surface with tile_y != 0.
    
    Instead, simply call intel_renderbuffer_tile_offsets to compute the
    actual X/Y offsets and check if either are non-zero.  This makes both
    the workaround and the assertion check the same things.
    
    Fixes piglit test fbo-generatemipmap-formats, and should also fix
    bugs #34009 and #39487.
    
    NOTE: This is a candidate for stable release branches.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34009
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39487
    Reviewed-by: Eric Anholt <eric@anholt.net>
    Reviewed-by: Chad Versace <chad@chad-versace.us>
    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>

I tested 7.11-rc4 and it works for me now.

Thanks, Sander

Closing as the original reporter confirmed the fix.