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.
- Based on driver pixmaps with some changes (completely transparent to driver).
- It helps with the problem of known software fallbacks, such as trapezoids.
- exaDoMigration is now called for all cases that provide a do_migration hook.
- exa_migration.c is renamed to exa_migration_classic.c
- Create a few seperate functions and a few private function pointers.
- Replace a few if conditions with a check for pExaPix->pDamage instead.
- This is in preperation of a third scheme that lies somewhere in between.
- Code clarity would have suffered (i started working on it and didn't like the mess).
Use reference counting and do nothing unless the reference count transitions
to/from 0.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=22822 .
As a bonus, this avoids calling the driver Prepare/FinishAccess hooks more than
once per pixmap and operation.
Also update the Doxygen documentation for the PrepareAccess driver hook to
better match current reality.
* Check all pixmaps involved for damage records, fixes visual corruption due to
the screen pixmap never having one.
* Fix an array size and remove a now superfluous assignment.
This way we don't always need to scan over previously allocated areas when
looking for an available one, and there might be less fragmentation.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
At most once per second, under the following circumstances:
* We can't satisfy an offscreen memory allocation, but there seems to be enough
offscreen memory available in total.
or
* The server has been idle for at least 100ms, and there is more than one
available offscreen area.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
This adds a revised pixmap hook for driver pixmaps, which is
required to support tiling on various chips.
Signed-off-by: Dave Airlie <airlied@redhat.com>
- Some image viewers (eog, gqview) trigger the CopyArea path of Xext/shm.c
- I'm not aware of any code path that wouldn't like UTS and trigger this code.
- miDoCopy should handle src coordinate clipping.
- Overlapping blits are obviously not an issue (both would have to be offscreen or not).
- fbChangeWindowAttributes can create pixmaps (and access them) without use preparing access.
- Also handle the destroyed pixmaps by finishing them first.
- Switch to DEST indices again in exaCreatePixmapWithPrepare, because they are obviously being rendered to.
- Also avoid calling FinishAccess on pixmaps that are destroyed (and their memory potentially invalid).
Michel Dänzer
Dave Airlie
Maarten Maathuis
Peter Hutterer
Ben Skeggs