Just embed the large elements in the regular pixmap private and
collapse the union to a single struct.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Otherwise the CPU may end up reading from non-cacheable memory, which is
very slow.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84178
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Markus Wick <markus@selfnet.de>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
These offer a simpler and more efficient means for temporarily
transitioning to CPU-accessible memory for fallback implementations.
v2: Do not attempt fallbacks with GLAMOR_DRM_ONLY pixmaps
glamor cannot transfer pixels for GLAMOR_DRM_ONLY pixmaps using
glReadPixels and glTexSubImage2D, and so there's no way to perform
fallback operations with these pixmaps.
v3: Clear ->pbo field when deleting the PBO. Otherwise, we'd reuse
the old name next time we fall back on the pixmap, which would
potentially conflict with some other pixmap that genned a new
name, or just do a lazy allocation of the name (compat GL context,
like we currently use) or error out (core GL context, like we hope
to use some day). Also, style fixes. Changes by anholt, acked by
keithp.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
