On Sat, Nov 12, 2016 at 11:00 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Sat, Nov 12, 2016 at 6:00 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> There are a handful of regressions as a result of this change: >> - fbo-generatemipmap-formats on compressed textures with irregular >> sizes fails. The 2+ levels appear as if their offsets were off by a >> bit. No idea why, despite a lot of staring. I suspect the fact that >> this test was passing before is pure coincidence as well. > > OK, I figured out why this was happening. Let's say you have a height > of 277 and a block size of 4. If you divide the 4 out straight away, > you're going to get miplevel heights of 70, 35, 17, 8, 4, 2, 1. If, on > the other hand, you start with the 277 size, you're going to get > miplevel heights of ceil(277/4)=70, ceil(138/4)=35, ceil(69/4)=18, > ceil(34/4)=9, ceil(17/4)=5, ceil(8/4)=2, ceil(4/4)=1. Mesa is > overwriting larger chunks than the allocation code expected, which is > why some data from various levels is ending up in the wrong places. I > think it should be moderately simple to fix the TilingFunctions code > to take this into account properly, will give it a shot.
OK, that fixes it - https://github.com/imirkin/mesa/commit/6231bc6acb7518c6e0453a6b25055f6f1ca92808 as a replacement for the other TilingFormats patch I sent earlier in this series, plus a very small change to this patch to make use of this functionality again. Updated version here: https://github.com/imirkin/mesa/commit/d6afb2ee9b75161864534521446b5fb624fbbe57 I'll wait to resend until I get some review comments. Cheers, -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
