We currently support two modes of operation for RW PBO buffers: one
that allocates a pack buffer with GL memory and one that uses system
memory when the former is not supported.
Since allocation with system memory is less likely to fail, add a
fallback to system memory when GL memory failed instead of bailing
out.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Packed buffer allocation (which happens at glBufferData time with the
buffer bound) can fail when there is no GL memory left.
Pick up the error when it happens, print a proper error message, do
some cleanup and bail.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Lots of the accel paths only make current once they start
doing someting, so a lot of them call the bail paths without
make current, which means on PRIME systems for example
we end up in the wrong context.
Add a prepare pixmap in the prepare fallback path.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90667
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This function takes the start x/y and the destination's width/height,
so it only works if there's no transform. We could potentially
transform this box and take its bounds with some rounding, but this at
least gets us to read out enough data.
Note that this does the same overshoot on destination pictures with a
transform attached, but that seems unlikely to be used anyway.
v2: Add XXX comment for the commit message note (Suggested by Michel).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
Reviewed-by: Dave Airlie <airlied@redhat.com> (v1)
v2: fixup whitespace
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
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>
Eric Anholt
Paul Kocialkowski
Dave Airlie
Alan Coopersmith
Keith Packard
Michel Dänzer