On Dec 11, 2016 12:28 AM, "Pohjolainen, Topi" <topi.pohjolai...@gmail.com> wrote:
On Tue, Dec 06, 2016 at 12:37:45PM -0800, Jason Ekstrand wrote: > Cc: "13.0" <mesa-sta...@lists.freedesktop.org> > --- > src/mesa/drivers/dri/i965/intel_blit.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/src/mesa/drivers/dri/i965/intel_blit.c b/src/mesa/drivers/dri/i965/intel_blit.c > index 03a35ee..5f0cf74 100644 > --- a/src/mesa/drivers/dri/i965/intel_blit.c > +++ b/src/mesa/drivers/dri/i965/intel_blit.c > @@ -421,8 +421,10 @@ intel_miptree_copy(struct brw_context *brw, > > assert(src_x % bw == 0); > assert(src_y % bh == 0); > - assert(src_width % bw == 0); > - assert(src_height % bh == 0); > + assert(src_width % bw == 0 || > + src_x + src_width == minify(src_mt->logical_width0, src_level)); > + assert(src_height % bh == 0 || > + src_y + src_height == minify(src_mt->logical_height0, src_level)); Can you given example how we can blit sub-block worth of data? Above there is check for src_x/y being block aligned don't all mipmap levels need to be aligned as well? For compressed textures, the width and height of the entire texture don't have to be block-aligned. When computing the size of a miplevel in blocks, you just round up to the nearest block and part of the last block may be outside the texture. This means that every time you have a subrectangle of a compressed textures, the upper and left edges have to be block-aligned and the lower and right edges have to be either block-aligned or be the left or right edge of the miplevel. Make sense? It's really annoying. > > src_x /= (int)bw; > src_y /= (int)bh; > -- > 2.5.0.400.gff86faf > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
