Bug 34009 - Automatic Mipmap Generation produces very blurry image.
Automatic Mipmap Generation produces very blurry image.
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965
7.10
x86-64 (AMD64) Linux (All)
: medium normal
Assigned To: Kenneth Graunke
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-07 15:06 UTC by Sander Jansen
Modified: 2011-09-26 23:09 UTC (History)
0 users

See Also:


Attachments
Medium => Blurry Texture (170.60 KB, image/png)
2011-02-07 15:06 UTC, Sander Jansen
Details
Small => Ok (93.34 KB, image/png)
2011-02-07 15:06 UTC, Sander Jansen
Details
Large => Ok (377.13 KB, image/png)
2011-02-07 15:07 UTC, Sander Jansen
Details
Software => Dark texture (142.69 KB, image/png)
2011-02-07 16:19 UTC, Sander Jansen
Details
3d accel disabled, pot texture + mipmapping (121.31 KB, image/png)
2011-06-14 12:09 UTC, Sander Jansen
Details
apitrace output (514.41 KB, application/octet-stream)
2011-07-19 11:40 UTC, Sander Jansen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sander Jansen 2011-02-07 15:06:09 UTC
Created attachment 43054 [details]
Medium => Blurry Texture

When using automatic mipmap generation one of the generated mip maps seems to be very blurry. 

I'm using opengl as an image viewer. The viewer can easily be resized, so when I did, I noticed that one of mip maps seems to be incorrectly renderd. 

For comparison, see the small, medium and large screenshots. (small and large seems fine)
Comment 1 Sander Jansen 2011-02-07 15:06:59 UTC
Created attachment 43055 [details]
Small => Ok
Comment 2 Sander Jansen 2011-02-07 15:07:35 UTC
Created attachment 43056 [details]
Large => Ok
Comment 3 Sander Jansen 2011-02-07 15:12:41 UTC
I'm guessing the black lines on the bottom of the picture are also a bug I think.
Comment 4 Sander Jansen 2011-02-07 16:17:48 UTC
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?
Comment 5 Sander Jansen 2011-02-07 16:19:18 UTC
Created attachment 43057 [details]
Software => Dark texture

When I turned off 3d acceleration in driconf, this was the result.
Comment 6 Sander Jansen 2011-02-07 16:46:11 UTC
(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).
Comment 7 Eric Anholt 2011-06-14 11:29:08 UTC
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.
Comment 8 Sander Jansen 2011-06-14 12:08:06 UTC
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
Comment 9 Sander Jansen 2011-06-14 12:09:17 UTC
Created attachment 47966 [details]
3d accel disabled, pot texture + mipmapping
Comment 10 Eric Anholt 2011-07-19 10:50:32 UTC
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)
Comment 11 Sander Jansen 2011-07-19 11:02:47 UTC
(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
Comment 12 Sander Jansen 2011-07-19 11:40:47 UTC
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.
Comment 13 Kenneth Graunke 2011-07-25 11:58:10 UTC
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.
Comment 14 Kenneth Graunke 2011-07-28 14:05:54 UTC
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>
Comment 15 Sander Jansen 2011-07-31 07:30:35 UTC
I tested 7.11-rc4 and it works for me now.

Thanks, Sander
Comment 16 Kenneth Graunke 2011-09-26 23:09:48 UTC
Closing as the original reporter confirmed the fix.