Replace the current score keeping algorithm with a rolling counter that's
incremented in ExaOffscreenMarkUsed, with the previous value being stored
in the area. exaOffscreenAlloc uses the difference between the counter
value and the value in the area when deciding which area to evict.
It now also takes the size of the areas into account, and favors evicting
smaller areas.
The credit for these ideas goes to Michel Dänzer.
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 is a new behavior for version 2.1 of EXA, and only takes effect if the
driver has requested that. Otherwise, the previous behavior remains the same.
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.
dependencies. It was nearly abstract enough already to be used by
multiple DDXes. This will be useful for EXA development through
providing a fake acceleration implementation within Xephyr, so that
testing can be done on new EXA code without worrying about buggy
drivers.
causing our search loop for evictable blocks to possibly skip a good
candiate, and another was the allocator would occasionally use
area->offset as if it was the base of the pixmap, while for a pixmap
that is not in available state, it is not. This caused some funny
miscalculation leading to overlapping pixmaps and accesses beyond the
end of the framebuffer. To make things cleared, I renamed save_offset
to base_offset, made sure it's the one used everywhere in the
allocator, and only align "offset" for the client at the end of
exaOffscreenAlloc().
hook so we can upload a subset of a pixmap, and convert the current
drivers to respect that. Use this support to directly UploadToScreen in
exaGlyphs, providing a 47.4% +/-2.4% decrease in wall time for ls -lR
programs/Xserver in an antialiased gnome-terminal on an M6 (n=3, caches
hot). I would have bumped major version, only I can't tell what the
EXA_VERSION_* is supposed to be doing as opposed to the module version.
around CPU access to the framebuffer. This allows the hardware to set
up swappers to deal with endianness, or to tell EXA to move the pixmap
out to framebuffer if insufficient swappers are available (note: must
not fail on front buffer!).
Submitted by: benh
simplify/clarify it for driver writers who probably don't want to know
what pPixmap->devPrivate.ptr or pPixmap->devKind mean. Converts the sis
driver to use them, and bumps the EXA module minor version.
