Turns out this is still necessary if the driver PrepareAccess hook succeeds.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Tested-by: Maarten Maathuis <madman2003@gmail.com>
Tested-by: Andrew Chant <andrew.chant+debian@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We want to save the result in the system memory copy, in case we'll need it
again for subsequent software fallbacks.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Acked-By: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
[ Michel: Minor fixups to address compiler warnings ]
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Acked-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is more elegant and probably also slightly more correct than doing it
at FinishAccess time.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Acked-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When we can trivially calculate the affected source regions,
do that before calling region bounded prepareAccess.
[ Michel: Minor fixups to address compiler warnings ]
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Acked-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
* With optimized migration, only the pending damage region is synchronized for
destination pixmaps.
* Migration of source pixmaps can be limited to a bounding region.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Acked-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=25536 .
There should be no reason for the pitch to actually change when none of the
other dimensions do, and this could lead to incorrectly freeing the system
memory copy when allocating a GPU copy, resulting in loss of valid pixmap
contents.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Acked-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
* Better detection of dimension changes.
* Make sure to re-create the system memory copy when the pixmap dimensions
change (e.g. the screen pixmap on screen resize).
* Clear the valid regions.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Acked-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Only return TRUE if the GPU copy is being accessed, and preserve the return
value on repeated / nested calls for the same pixmap.
exaPrepareAccessReg_mixed could get inconsistent return values e.g. when the
same pixmap is both the destination and source of an operation, potentially
resulting in a crash.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Acked-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
- When they have a gpu copy ofcource.
- Use the presence of a cpu copy as a hint to fall back instead of UTS'ing in
exaHWCopyNtoN.
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Acked-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Fixes incorrectly skipped rendering of some Composite operations to windows.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This reverts commit 99d88ef69d.
- Some pixmaps under classic have a sys_pitch which is 0, no idea why. This is
causing rendering corruption.
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Acked-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=24300 .
Offscreen memory allocation can occur from various places, and apparently
doing defragmentation from at least some of them can confuse some driver
acceleration code.
There's still the regular background defragmentation in the WakeupHandler,
which should manage to keep fragmentation at a reasonable level.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This reverts commit c11678cc18.
Not sure what I was thinking, turns out alloca() of a size derived from client
input is a bad idea.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
- Setting pitch before exaCopyDirty* is not needed.
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Acked-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
- Fixup some variable names as well.
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Acked-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
- Pixmaps that are created during a fallback are automatically prepared access.
- During the fallback accelerated ops are blocked to prevent new/scratch gc's
from triggering accelerated ops on mapped pixmaps.
- A few cases of incorrect wrapping (on the top level pointer instead of
between damage and (w)fb) have been removed.
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Acked-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This reverts commit d4fc245115.
- This is causing crashes/problems for some.
Acked-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
- When the driver handles the prepare access no copying is needed.
- Delayed pixmap creation should be fine, because it's handled by the
first prepare access, but the exaPixmapIsOffscreen check in finish access
will return FALSE without a driver pixmap.
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Acked-by: Michel Dänzer <michel@daenzer.net>
It crash the server when the drawable is 32 bit and the framebuffer is 16.
This is pretty much a copy-past from commit 8e873185.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
- This comment is still in exa_driver.c and there it makes sense.
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Acked-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Solid pictures have a NULL pFormat field, but their format is always
PICT_a8r8g8b8.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Easily reproducible by running "rendercheck -t fill".
It should be safe to just test against rbits for all colour components
as we should always have values for r/g/bbits for PICT_FORMAT_COLOR
formats.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Michel Dänzer <daenzer@vmware
Signed-off-by: Keith Packard <keithp@keithp.com>
The upload in finish access can cause an infinite loop if
UTS returns FALSE in here.
Fixes fd.o bug #24246.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For the recent mixed pixmaps changes, I failed to realize (or hit in my
testing) a problem which can occur if the driver doesn't provide an
UploadToScreen hook or provides one which can fail: There can be a crash
in exaMemcpyBox() because exaCopyDirtyToFb() passes pExaPixmap->fb_ptr to
exaCopyDirty(), but that's normally NULL with driver allocated pixmaps.
The solution is to make exaCopyDirty*() no longer rely on pExaPixmap->fb_ptr
but use pPixmap->devPrivate.ptr after PrepareAccess instead.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=24167 .
If there are several software fallbacks affecting the system memory copy of the
same pixmap, only copy the results back to the driver pixmap when it's used for
acceleration again, or in the BlockHandler, whichever happens first.
If the PrepareAccess hook fails, use the DownloadFromScreen hook to retrieve
driver pixmap contents to a system RAM copy, perform software rendering on that
and copy the results back using the UploadToScreen hook. Use the classic
migration logic to minimize transfers (which as a bonus allows slightly
cleaning up some of the existing mixed pixmap code).
This enables things that weren't possible before with driver-allocated pixmap
storage: If some (or all) GPU pixmap storage can't be mapped directly by the
CPU, this can be handled between the PrepareAccess and
DownloadFrom/UploadToScreen hooks, e.g.:
* Radeon KMS on big endian machines can fail PrepareAccess if the pixmap
requires byte-swapping and swap bytes in DownloadFrom/UploadToScreen.
* Environments where GPU and CPU don't have a shared address space at all.
Here the driver PrepareAccess hook will always fail and leave all transfers
between GPU / CPU storage to the Download/From/UploadToScreen hooks.
Drivers which can handle all pixmaps in the PrepareAccess hook should notice
little if any difference.
It doesn't make sense for windows.
Also double-check that the data pointer is valid.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=23461 (not sure that could
happen on master even without this, but just in case)
Add support for solid pictures in exaTryDriverSolidFill(), but otherwise just
pass solid and gradient pictures to the driver Composite hook.
While we're at it, clean up the logic to detect Composite operations which are
effectively solid fills or copies. This should also fix some false negatives
and positives.
