On Mon, Aug 31, 2015 at 10:29:51PM -0700, Jason Ekstrand wrote:
> On Aug 31, 2015 6:48 AM, "Chris Wilson" <[1]ch...@chris-wilson.co.uk>
> wrote:
> >
> > From: Jason Ekstrand <[2]jason.ekstr...@intel.com>
> >
> > If the user is specifying a subregion of a buffer using SKIP_ROWS and
> > SKIP_PIXELS, we must compute the buffer size carefully as the end of the
> > last row may be much shorter than stride*image_height*depth. The current
> > code tries to memcpy from beyond the end of the user data, for example
> > causing:
> > Fixes: 7f396189f073d626c5f7a2c232dac92b65f5a23f
>
> How can this fix a SHA? What repo is this SHA in?
I suppose it is an actual regression from
commit 7f396189f073d626c5f7a2c232dac92b65f5a23f
Author: Jason Ekstrand <jason.ekstr...@intel.com>
Date: Mon Jan 5 18:17:04 2015 -0800
meta: Add a BlitFramebuffers-based implementation of TexSubImage
> > if (is_pixel_pack)
> > - _mesa_BufferData(pbo_target, row_stride * height, NULL,
> > + _mesa_BufferData(pbo_target,
> > + last_pixel - first_pixel,
> > + NULL,
>
> I'm trying to decide if the null here is correct... It's certainly the
> same as what we had before but I have a nagging feeling that this should
> be (void *)first_pixel.
It should be NULL, but the code doesn't work for the GetTexSubImage
case as it does a GPU copy into the buffer object that it creates but
then never reads it back from the buffer object into the client memory.
Fortunately the non-pbo path is not used for GetTexImage.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
