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
