Avoid writing out of range data over valid data in CVTT decompress methods when decompressing small mip levels

[clayjohn]

I noticed this while debugging #90873

Bug

When decompressing a BPTC texture, the last column of pixel for all mipmaps from levels 16x16 and lower would be black

This results in the last miplevel being totally black since it only has one column.

I can reproduce this bug in 4.3, 4.2, and 4.1. I haven't tested earlier versions.

Problem

The problem comes from how we decompress the image. A block in BPTC is a 4x4 group of pixels. We decompress 8 blocks at a time (this isn't necessary, but it seems like it was done to allow us to trivially parallelize decompression). Which means that we decompress a 32x4 group of pixels at once.

Once you have a mip level with a width smaller than 32 we decrease the number of blocks that we copy over into the input buffer. However, we still process the invalid blocks (they are zeroed out) and we still attempt to copy them over to the final image. Only the last column is affected because the logic for writing pixels greater than width is to write them out at width - 1.

Solution

When calculating the end of the region to write pixels, we take into account the number of blocks that we are processing and we don't read back pixels from blocks that are totally zeroed out. This way we only copy back data from valid blocks

Before:

After:

[akien-mga]

CC @BlueCube3310

[BlueCube3310]

LGTM

[akien-mga]

Thanks!