Commit Graph

7 Commits

Author SHA1 Message Date
Michel Dänzer
0bd8f0cd7f EXA/classic: Fix crash with migration heuristic "smart".
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Acked-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
2009-12-29 11:04:07 -08:00
Maarten Maathuis
a54c23fe64 exa: s/PixmapIsOffscreen/PixmapHasGpuCopy and s/pExaPixmap->offscreen/pExaPixmap->use_gpu_copy
- 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>
2009-11-28 12:44:58 -08:00
Michel Dänzer
b5fcc5553e exa: avoid infinite loops if UTS sw fallbacks.
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>
2009-10-01 15:52:28 +10:00
Michel Dänzer
73ae547d5e EXA: Fix mixed pixmaps crash with missing / failing UploadToScreen hook.
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 .
2009-09-27 02:08:10 +02:00
Michel Dänzer
1818cbd70f EXA: Extend mixed pixmaps scheme to allow driver PrepareAccess hook to fail.
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.
2009-09-26 01:59:39 +02:00
Maarten Maathuis
e8ac2ed5dc exa: implement exaMoveInPixmap for "mixed"
- This can be used to force creation of driver pixmap.
- Not for 1 or 4 bpp.
- Driver can still fail (driver) pixmap creation.
2009-08-06 23:48:14 +02:00
Maarten Maathuis
03ecb164f2 exa: A simple 3rd backend implementation.
- 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
2009-08-06 23:48:14 +02:00