| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Conflicts:
hw/xnest/Pixmap.c
include/dix.h
|
|
|
|
Conflicts:
dix/dispatch.c
dix/property.c
hw/xfree86/common/xf86VidMode.c
include/xkbsrv.h
render/glyph.c
xkb/xkbActions.c
|
|
These hints allow an acceleration architecture to optimize allocation of certain
types of pixmaps, such as pixmaps that will serve as backing pixmaps for
redirected windows.
|
|
Conflicts:
GL/glx/glxscreens.c
hw/xnest/Screen.c
render/glyph.c
render/glyphstr.h
render/render.c
|
|
Not all of the DDX/miext Glyphs hook implementations have been removed, but
they should be.
|
|
Conflicts:
os/access.c
|
|
|
|
|
|
|
|
|
|
In exaDriverInit(), quickly check if the programmer forgot to set some
mandadory driver hooks, in that case display a meaningful error message.
|
|
|
|
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
|
|
|
|
This doesn't add real value yet, but it will be useful once I add code
that splits large render operations into smaller parts if necessary.
|
|
exaCreatePixmap should handle all cases correctly.
|
|
Conflicts:
dix/devices.c
|
|
Drivers can now specify the max pitches that the accelerator supports.
|
|
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.
|
|
Conflicts:
afb/afbpntwin.c
afb/afbscrinit.c
afb/afbwindow.c
cfb/cfb.h
cfb/cfballpriv.c
cfb/cfbscrinit.c
cfb/cfbwindow.c
configure.ac
fb/wfbrename.h
hw/xfree86/xf4bpp/ppcIO.c
hw/xfree86/xf4bpp/ppcPntWin.c
hw/xfree86/xf4bpp/ppcWindow.c
hw/xfree86/xf8_32bpp/cfbscrinit.c
mfb/mfb.h
mfb/mfbpntwin.c
mfb/mfbscrinit.c
mfb/mfbwindow.c
mi/miexpose.c
Note: conflicts caused by devPrivates rework vs. paintwindow changes.
|
|
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.
|
|
Also consolidate exaCopyDirtyToFb/Sys.
|
|
Also fix exaFinishAccessGC not to use the same index for tile and stipple.
|
|
|
|
over to new system.
Need to update documentation and address some remaining vestiges of
old system such as CursorRec structure, fb "offman" structure, and
FontRec privates.
|
|
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.
|
|
Share as much code with exaPutImage as possible, and fall back to fbShmPutImage
when that fails.
|
|
The result was that at 32bpp, pixmaps of width 8192 or greater couldn't be
created, due to treating a pitch value as a width.
|
|
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.
|
|
EXA may attempt to use the invalid value and crash otherwise.
|
|
Convert the remaining callers to PixmapDirty.
|
|
* 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.
|
|
"offscreen" in exa terms, which means accessible to the GPU.
Bump exa minor. The change is backwards-compatible.
|
|
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.
|
|
Conflicts:
exa/exa_accel.c
exa/exa_migration.c
|
|
See https://bugs.freedesktop.org/show_bug.cgi?id=6772 .
|
|
This will hopefully fix the partial window corruption experienced by some
people.
|
|
|
|
Move variable declarations to start of blocks as required by c89
|
|
|
|
out how much memory EXA is managing for offscreen pixmaps.
|
|
Based on work by Eric Anholt.
|
|
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.
|
