| Age | Commit message (Collapse) | Author |
|---|
|
|
|
In theory the driver should be able to handle the front buffer not at VRAM 0
In practice it didn't.. this is cleanup for at least XAA parts of the driver
to allow for the frontbuffer to move. It has to re-organise a large part of ScreenInit so things happen in the correct order otherwise some things get setup in-correctly. (not sure EXA with fb not at 0 works yet...)
|
|
Also use the damage layer directly instead of via shadowfb and blit dirty
rectangles to the second page in LeaveServer in order to try and improve the
tradeoff between performance and correctness.
|
|
|
|
OTOH, flush everything when the previous engine mode is unknown, and mark the
engine mode as unknown in a couple more cases.
|
|
|
|
As a result, quite a bit of code can be removed that attempted to deal with the
EXA offscreen memory disappearing, with varying success. Because the HW cursor
memory is now always immediately after the front buffer and before the back
buffer, this also fixes bug #6808.
As the HW cursor memory is now reserved statically with EXA and XAA, change
RADEONUseHWCursor() to check info->cursor instead of info->cursor_offset, for
which 0 might become valid with HW cursor enabled in the future.
Change info->cursor_offset from unsigned long to CARD32 as the corresponding
register is 32 bits wide, and to avoid issues with printf.
|
|
Thanks to Matthieu Herrb for pointing out some of these.
|
|
This allows getting higher depth buffer precision and stencil hardware
acceleration in depth 16 or saving some video RAM at the cost of these features
in depth 24.
|
|
|
|
moving all the accel and card members into the driver ptr, filling in
the exa_major/ exa_minor fields, and always using LoadSubModule so we
can check the module version up front. Only tested on ATI.
|
|
OpenGL textures with EXA.
|
|
the clients to get access to a secure area of framebuffer.
|
|
coordinates rather than integers.
|
|
Include "compiler.h" to define __inline__ on non-gcc compilers
|
|
RADEONHostDataBlit.
- Disable the shortcut for switching from 3d to 3d in radeon_exa.c. It
appears that we do need the cache flush here, thought it's not clear
why. Disable the 2d to 2d shortcut while here, since I'm unsure of what
we're doing. Exposed by the following bit:
- Bug #4485: Add a new routine, exaGlyphs, to handle font drawing. Glyphs
were being accumulated in from non-migratable scratch pixmaps, causing
the destination pixmap to move towards screen but the migration
necessary for source never to happen, leading to abysmal performance.
Instead, copy the scratch glyph data into a real pixmap first, then
composite from that into the destination, allowing for migration. time
ls -lR from programs/Xserver showed 26.9% (+/- 6.3%) decrease in wall
time (n=3).
- Create exaDrawableUse* wrapping exaPixmapUse*, but which are aware of
windows needing backing store. Makes migration code prettier, and
ensures that composited windows will be migrated as normal when we turn
off cw for EXA. (issue brought up by keithp)
|
|
allow for PCI/AGP/PCIE cards. Set PCI gart allocation to only happen on
PCIE cards. Add Radeon PCIE card detection using capability bits.
|
|
|
|
controlled at compile time, plus the runtime option of Option
"AccelMethod" "EXA" or "XAA". The XAA support appears to remain as
before, while the EXA pieces need just a little more polishing. Notable
features:
- Render acceleration working on Radeon 100 and 200-series with DRI on.
- DRI works with EXA Notable issues:
- DGA disabled in the EXA case.
- Backbuffer moves disabled in the EXA case.
- No textured XVideo.
- MMIO render acceleration is close but still has some issues.
- Memory pressure while using Composite is really troublesome with DRI on.
This patch is based on an initial patch by Zack Rusin, with significant
work by Benjamin Herrenschmidt and myself.
|
