Thanks Neil, I'll make that change. Should be simple enough. --Jason
On Mon, Aug 4, 2014 at 10:51 AM, Neil Roberts <n...@linux.intel.com> wrote: > One case where the memcpy path won't work is if the source and > destination are the same buffer. In that case it tries to map the > texture twice and hits an assert. I think this could be a legitimate use > case if the source and destination rectangles don't overlap. The > extension spec isn't very clear on whether this is allowed but the spec > for GL 4.4 actually mentions blitting between a single buffer and > implies that it's ok if the rectangles don't overlap. Perhaps one way to > solve this would be to check if src_mt==dst_mt and if so it could map > the union of both rectangles as read and write. It would then have to > manually offset the source and destination pointers to the right place. > > You might also want to update the commit message as the patch is no > longer restricted to a pitch of at most INT16_MAX. > > Regards, > - Neil > > Jason Ekstrand <ja...@jlekstrand.net> writes: > > > This, together with the meta path, provides a almost-complete > implemetation > > of ARB_copy_image. The only case that won't work is if one of the > textures > > is compressed and has a pitch greater than INT16_MAX. I think that's > good > > enough to justify turning on the extension. > > > > v2: Add a fallback memcpy path for when the texture is too big for the > > blitter > > > > Signed-off-by: Jason Ekstrand <jason.ekstr...@intel.com> > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
