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. Cheers, -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
