[Mesa-dev] [PATCH 5/5 v2] i965: Add support for ARB_copy_image

[Jason Ekstrand]

Thanks Neil,
I'll make that change.  Should be simple enough.
--Jason


On Mon, Aug 4, 2014 at 10:51 AM, Neil Roberts <neil at 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 <jason at 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.ekstrand at intel.com>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140804/e16c9609/attachment.html>