Age | Commit message (Collapse) | Author |
|
In order to avoid stalling on previous frame.
OTOH without KMS we can't do this but have to wait for the previous frame to
finish rendering.
|
|
Inspired by the intel driver; might avoid/reduce HW cursor flicker in some
cases.
|
|
|
|
Remove a message on driver startup which directs people to the old GATOS
website; said site contains highly out of date software which is no longer
necessary.
|
|
This will fallback to shadowfb is GPU accel failed somewhere during
KMS kernel init.
|
|
fixes fdo bug 24158.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
drm crtc ids do not correspond to actual hw crtcs,
as such the vline stuff was never enabled for Xv.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
|
|
|
|
|
|
fixes Xv after changes in:
8f80e37eed3ec028718b4e71bbb9b598847fd94e
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
the r6xx space check code was incorrect for the DFS case, since
the dst bo was in GTT but the hardcoded cp_start function
assumed the bos were where it thought.
Ripped out assumptions and replaced with code more like other radeons.
|
|
leftover from the randr 1.2 conversion.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Can be dangerous with kms:
http://lists.freedesktop.org/archives/xorg-devel/2009-September/002113.html
|
|
fixes cursor problems in games like UT2004 and Penumbra Overture
see fdo bug 24034
|
|
this thing can be rendering to VRAM when we don't expect it.
turn it off.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This fixes compilation if libdrm_radeon is installed to non-standard location like /opt.
|
|
Should be DVI-I, not DVI-D
|
|
|
|
unmapping was getting unbalanced.
|
|
this adds support to the userspace DDX to get properties from the kernel
and expose them over randr. Its most liberated from the Intel driver.
|
|
|
|
|
|
|
|
I'm not so sure the vb map/unmap is a good idea, I think
it pretty much locksteps the cpu/gpu, so we should really
work out if we really need to flush this often, since
mesa doesn't have to and we are just doing 3D ops.
|
|
deb bug 545040
|
|
In particular, also catch them for >= R300.
|
|
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=22636 .
Now, where's that brown paper bag? :}
|
|
|
|
unless we scale all the bos up to POT
|
|
|
|
Copy/paste bug from when kms support was added.
|
|
Bump requirement for xserver in KMS mode to 1.6.2 for DRI2Buffer2Ptr.
|
|
this fixes the driver complaining though reportedly it still does
not work (on r100)
|
|
Apparently changing pPict->repeatType causes badness, see
http://bugs.freedesktop.org/show_bug.cgi?id=23560 .
Now we just use a normalized repeatType value derived from pPict->repeat and
pPict->repeatType everywhere.
|
|
libdrm_radeon always takes care of this implicitly now.
|
|
Direct CPU writes should be at least as fast in that case.
|
|
* Drop superfluous RADEONDownloadFromScreenGTT function, EXA does the same
thing when we return FALSE.
* Take unflushed operations into account for determining which GEM domain the
pixmap BO will end up in.
* Only use a blit if it ends up in VRAM.
|
|
This is the intention with EXA in xserver Git, and IME it improves performance
significantly even with older versions.
|
|
|
|
We can't rely on the server setting pPict->repeatType to something sensible
when pPict->repeat is FALSE, but we can do it ourselves.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|