Changing WIDTH and HEIGHT in progs/tests/mipmap_limits to 2048 leads to correct mipmap level 0, images of levels >1 rendered on top of level 1 and black levels >1. Choosing somewhat smaller values for WIDTH results in other unwanted effects: besides damaged mipmap levels in mipmap_limits, sometimes pixmaps of other applications get corrupted, sometimes followed by a system crash(i have seen both panik and freeze). (gluScaleImage being broken does not help with the visual inspection, either. it works only with widths evenly dividable by 4.) When using the generated mipmap levels in mipmap_limits(key t), only level 1 shows damage, but i still sometimes get corrupted pixmaps in other applications.
This only happens with tiling enabled, automatic mipmaps are correct with tiling disabled using driconf.
mesa commit e885cb48a0b9292b3df9204f1c2783bf1fe29a28 adds another problem, only 1/4th of the original mipmap level is scaled, rest filled with black pixels. I didn't test if this is limited to large mipmaps, but this happens independently of tiling used.
OK, the original problem of this report is fixed now. commit 2d17dbfb5346b6d75e87c839148cbe125bf5cd6d Author: Eric Anholt <eric@anholt.net> Date: Thu Jul 9 09:32:21 2009 -0700 intel: Keep track of x,y offsets in miptrees and use them for blitting. By just using offsets, we confused the hardware's tiling calculations, resulting in failures in miptree validation and blit clears. Fixes piglit fbo-clearmipmap. Bug #23552. (automatic mipmap generation)
Hmmm, on my i965 the first three squares are red, green, blue but the rest are black. Anyone else? Re-opening.
Ignore the previous commit. My own debug code was screwing things up. However, there's still another issue. I changed the test to also draw a white triangle in the middle of each mipmap level. The white triangle appears in the right place for the first two mipmap levels, but not the subsequent levels. I'll attach the test program next...
Created attachment 30709 [details] modified test which also draws white triangles
Created attachment 30710 [details] [review] patch for intel_span.c to adjust x/y tiling offset OK, found the problem. When drawing to mipmap levels 2 or higher we're hitting a software fallback because of tiling restrictions (I have an non-G45 model). In the fallback/span code we're neglecting to add the region draw x/y offsets. The attached patch fixes this for me but I'd like someone (Ian, Eric?) to review it before I commit it.
Adding Eric to cc list.
I'm going ahead and committing this. I've been testing things all day and haven't seen any regressions. Committed to 7.6 branch as b7eea8c616092f5473a323fba585b04c47ae2010
I'm re-opening this bug. On G45-class hardware the clear (blit) is OK, but rendering into the various mipmap levels is incorrect. I'm attaching a new version of fbo-clearmipmap.c that demonstrates the problem. It appears that the surf.ss5.x_offset, y_offset calculations are incorrect in brw_update_renderbuffer_surface(). I'll attach a patch that fixes it to some extent, but it's still not correct for all cases. I suspect that we'll need to fall back to sw rendering for some mipmap levels/layouts, but I don't know the conditions for that. Ian, Eric, can either of you take a look at this?
Created attachment 31002 [details] new version of piglit fbo-clearmipmap.c that draws a tri into each texture
Created attachment 31003 [details] [review] patch which fixes the x/y offsets, somewhat This patch improves things a a little bit. A step in the right direction, I think. Note that there's some temporary _mesa_debug() code in this patch.
commit 63610fae4f46361f2500577a83bf5ac6f9e8b0ac Author: Eric Anholt <eric@anholt.net> Date: Mon Jan 4 08:47:01 2010 -0800 i965: Fix the surface offset calculation for tiled buffers. If we ever had a non-tile-aligned tiled renderbuffer, the math was all off. Use the existing x,y coordinates instead of trying to reconstruct them from an incorrectly-calculated offset value.
Something still is wrong with even bigger sizes and tiling, but this time it seems to be a problem of the hardware reading the wrong bits, the smaller mipmap levels get rendered correctly. I found this: width x height result [3976..4096]x[3752..4096] black stripes [3976..4096]x[0..3744] works [3848..3968]x[3880..4096] black stripes [3848..3968]x[0..3872] works [3716..3840]x[4008..4096] black stripes [3716..3840]x[0..4000] works [0..3708] x[0..4096] works (Only sizes dividable by 8 are possible at the moment, so i tested only those. Additionally, i tested only the border between "works" and "black stripes". I needed to fix the comment#2 issue first; that will be posted at a different place.) Should i open a new bug for this mipmap error, or do you want to handle this here? I think this existed before 63610fae4f46361f2500577a83bf5ac6f9e8b0ac.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.