Markus Wick <[email protected]> writes:
> You haven't used reverse, upsidedown and closure. Aren't they needed? reverse and upsidedown are required when doing software overlapping blts; but glCopyPixels handles those internally. 'closure' is a left over from some ancient drawing code requirements; I can't remember what it was used for though. Something about passing driver state across the miDoCopy function interface. >> + glCopyPixels (dx1 + dx - src_box->x1, >> + dy1 + dy - src_box->y1, >> + dx2 - dx1, dy2 - dy1, GL_COLOR); > > This functions are deprecated fortunately. Please don't use them at all. > Glamor shall be used as hardware accelerated fallback, so we shouldn't > rely on uncommon features which may be implemented in software (eg on > nvidia) or not implemented at all (core, gles). There isn't anything else I *can* use. GL doesn't otherwise define the results for operations using the same object for source and destination. > I see two ways to handle overlapping copys: > - Emit lots of non-overlapping draw calls / blits / copys > - Create a temporary buffer and copy twice A separate path involving a temporary buffer is clearly what would be required where glCopyPixels is not available. Performance from glCopyPixels is likely to be better when available, so we should prefer it. > I guess GPUs have some special HW for this, but we can't use them on > OpenGL. memmove isn't parallelizable. Yes, Intel GPUs have the 'blt' engine which performs overlapped copies correctly, and glCopyPixels is how we get to that. I imagine the same is true for other GPUs. As this operation is critical for many existing X applications for scrolling data around, we really have to make sure that we hit the special hardware. >> + glDrawArraysInstanced(GL_TRIANGLE_STRIP, 0, 4, nbox); > > Do you think it's worth to add a fast path with glBlitframebuffer or > glCopyImageSubData? > Both should have a better GPU performance and glCopyImageSubData should > also have a lower CPU overhead. Should be easy to measure and see if either is faster than this code; then we could decide. -- [email protected]
pgptbI4tPwwAr.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
