|Summary:||Automatic Mipmap Generation produces very blurry image.|
|Product:||Mesa||Reporter:||Sander Jansen <s.jansen>|
|Component:||Drivers/DRI/i965||Assignee:||Kenneth Graunke <kenneth>|
|Status:||RESOLVED FIXED||QA Contact:|
|i915 platform:||i915 features:|
Medium => Blurry Texture
Small => Ok
Large => Ok
Software => Dark texture
3d accel disabled, pot texture + mipmapping
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 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 <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. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34009 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39487 Reviewed-by: Eric Anholt <firstname.lastname@example.org> Reviewed-by: Chad Versace <email@example.com> Signed-off-by: Kenneth Graunke <firstname.lastname@example.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.