This adds hooks for the driver to access Create/DestroyPixmap and ModifyPixmapHe
ader.
It allocates a 0 sized pixmap using fb and calls the driver routine to do
work of allocating the actual memory.
ModifyPixmapHeader is mainly required for hooking the screen pixmap which
isn't create by normal methods
If the driver isn't compatible to the server, all bets are off anyway wrt
the contents of the fields that we're validating, which can lead to bogus
error messages.
This was an attempt to avoid scratch gc creation and validation for paintwin
because that was expensive. This is not the case in current servers, and the
danger of failure to implement it correctly (as seen in all previous
implementations) is high enough to justify removing it. No performance
difference detected with x11perf -create -move -resize -circulate on Xvfb.
Leave the screen hooks for PaintWindow* in for now to avoid ABI change.
Exclude bits that will be overwritten from migration.
Use exaGlyphs even when Composite can't be accelerated, to avoid PolyFillRect
roundtrip via offscreen memory.
Initialize mask pixmap in exaGlyphs in FB in addition to system if the driver
provides Composite hooks to avoid migration overhead.
Remove manual damage tracking where superfluous.
Only migrate once in exaTrapezoids/Triangles instead of every time in
exaRasterizeTrapezoid/AddTriangles. Adapt manual damage tracking to new
infrastructure.
Also move definition of NeedsComponent() closer to where it's used.
We finally want to catch all cases where the pixmap pointer is dereferenced
outside of exaPrepare/FinishAccess.
Also fix a couple of such cases exposed by this change.
The initiator of migration can pass in a region that defines the relevant area
of each source pixmap or the irrelevant area of the destination pixmap. By
default, the pending damage region is assumed relevant for the destination
pixmap, and everything for source pixmaps.
Thanks to Jarno Manninen for reassuring me that my own ideas for this were
feasible and for providing additional ideas.
Composite's automatic redirection is a more general mechanism than the
ad-hoc BS machinery, so it's much prettier to implement the one in terms
of the other. Composite now wraps ChangeWindowAttributes and activates
automatic redirection for windows with backing store requested. The old
backing store infrastructure is completely gutted: ABI-visible structures
retain the function pointers, but they never get called, and all the
open-coded conditionals throughout the DIX layer to implement BS are gone.
Note that this is still not a strictly complete implementation of backing
store, since Composite will throw the bits away on unmap and therefore
WhenMapped and Always hints are equivalent.
miTrapezoids creates an alpha pixmap and initializes the contents
using PolyFillRect, which causes the pixmap to be moved in for
acceleration. The subsequent call to RasterizeTrapezoid won't be
accelerated by EXA, which causing the pixmap to be moved back out
again.
By wrapping Trapezoids and using ExaCheckPolyFillRect instead of
PolyFillRect to initialize the pixmap, we avoid this roundtrip.
* Support planemasks, different ALUs and arbitrary tile origin.
* Leave damage tracking and non-trivial fallbacks to callers.
* Always migrate for fallbacks.
This is in preparation for using these from more other functions.
Additionally, protect libcw setup behind checks for Render, to avoid
segfaulting if Render isn't available (xnest).
The previous setup was an ABI-preserving dance, which is better nuked now.
Now, anything that needs libcw must explicitly initialize it, and
miDisableCompositeWrapper (previously only called by EXA and presumably binary
drivers) is gone.
This has been what has been used the most successfully post-damagetrack.
The current thinking is that:
1) We should be able to accelerate basically everything. So we don't need to
try to migrate trees of pixmaps permanently out of framebuffer to speed
CPU drawing up.
2) Migration is cheaper in the thrashing case, so we don't want to go to a lot
of effort to try (and fail badly) to find a working set.
Mostly due to exaDrawableDirty() now calculating the backing pixmap coordinates
internally, for cases where they aren't trivially known. There's a new
exaPixmapDirty() function for the other cases.
one behaves somewhat between Greedy and Always. It moves in if we can
accelerate, unless the destination is clean and shouldn't be kept in
framebuffer according to the score, in which case we migrate out (and
force-migrate anything where migration is free). This should help fix
lack of acceleration for drivers without UTS since removing
exaAsyncPixmapGCOps, and has removed one performance trap with Radeon
I'd noticed. It is the new default.
devPrivate.ptr when pointing at offscreen memory, outside of
exaPrepare/FinishAccess(). This was used with fakexa to find (by NULL
dereference) many instances of un-Prepared CPU access to the
framebuffer:
- GC tiles used in several ops when fillStyle == FillTiled were never
Prepared.
- Migration could lead to un-Prepared access to mask data in render's
Trapezoids and Triangles
- PutImage's UploadToScreen failure fallback failed to Prepare.
plug in the accelerated one, even if the destination pixmap is
currently offscreen. This was a leftover from when kaa originally got
accelerated offscreen pixmap support, and its only concievable use was
to avoid a little overhead on ops to in-system pixmaps that weren't
going to get migrated. At this point, we probably care more about just
getting everything accelerated that we easily can, which should happen
with the new migration support.
pixmap, and damage is tracked so that a later exaMoveInPixmap won't
result in an upload if no upload is necessary. This will likely improve
the performance of the "Always" migration scheme significantly, and is
a step in the path to more exact damage tracking between framebuffer
and system memory.
desired location always (unless they don't fit in FB, in which case
they all get moved out for software rendering). The default remains as
before, but can be controlled by the MigrationHeuristic xorg.conf
option (which is intentionally not documented, as it may be
short-lived). This is part of the exa-damagetrack work, which appears
stable in testing with fakexa, unlike the work as a whole.
manual conversion to allow for different migration schemes to be
implemented reasonably, but does include some minor improvements such
as accounting for pinned pixmaps not being acceleratable, and for our
current GetImage and GetSpans not being accelerated.
corresponding pieces of exa-driver.txt, which were becoming stale.
Hopefully the documentation will stay much more up-to-date this way.
Many thanks to jbarnes for writing exa-driver.txt which was used a lot
in writing this documentation.
when extending the driver interface. The card and accel structures are
merged into the ExaDriverRec, which is to be allocated using
exaDriverAlloc(). The driver structure also grows exa_major and
exa_minor, which drivers fill in and have checked by EXA
(double-checking that the driver really did check that the EXA version
was correct). Removes exaInitCard(), which is replaced by the driver
filling in the rec by hand, and the exaGetVersion() and related
EXA_*VERSION which are replaced by always using the XFree86 loadable
module versioning.
