Bugzilla – Bug 34009
Automatic Mipmap Generation produces very blurry image.
Last modified: 2011-09-26 23:09:48 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)
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.
Since it has been a couple of months, I retested it again with pretty much the same results.
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:
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
Ok, I'll try out apitrace and will post the results.
-- chipset: 965GM
-- system architecture: x86_64
-- kernel version: 2.6.39-ARCH
-- Linux distribution: Arch Linux
-- Machine or mobo model: Toshiba U305
-- Display connector: LVDS
Created attachment 49307 [details]
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:
Author: Kenneth Graunke <email@example.com>
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.
Reviewed-by: Eric Anholt <firstname.lastname@example.org>
Reviewed-by: Chad Versace <email@example.com>
Signed-off-by: Kenneth Graunke <firstname.lastname@example.org>
I tested 7.11-rc4 and it works for me now.
Closing as the original reporter confirmed the fix.