Fixes regression from
commit e3f15cbf39 [2.99.905]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Oct 22 15:19:15 2013 +0100
sna: Move gc back to GPU after failure to move it to CPU
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Expunge our caches if we fail to write into a bo (presuming that
allocation failure is the likely fixable cause).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After computing the clip intersection, we immediately check for the
empty result, so refactor the check into the common routine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For consistency with the other aperture metrics and correctness when
passing around required number of pages.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we get a pageflip fail when trying to do a TearFree update, just
fallback to a copy (before turning off the display for complete
failure). The rare tearing copy should mar the user experience far less.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This will overcount buffers that both fenced and unfenced (likely most
fenced buffers!) but is required to prevent ENOSPC due to alignment
issues.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
kgem_check_bo_fenced queries whether the GPU is idle, and so its result
is timing dependent and not suitable for assertion.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes a regression introduced in
commit 4d2840919f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Sep 26 15:30:58 2013 +0100
sna: In desperation, query the actual available aperture space
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
DamageRegionAppend() will itself apply the drawable offsets, so we need
to pass it the untransformed region. This also fixes an issue where we
might fallback without applying any Damage.
Reported-by: Christian Nassau <nassau@nullhomotopie.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32734
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Whoops. Only the kernel sprintf() accepts NULL as a valid target string,
not libc's.
Reported-by: Jay Little <jaylittle@jaylittle.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70835
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Otherwise we may not correctly undo COW or pending move-to-gpu updates.
v2: goto move_to_gpu instead for correcting the damage handling.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70821
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we fail to allocate an alternate bo to replace the still visible
scanout bo, we stall and were supposed to continue using the old
wait->bo. However, we chose to use NULL instead which is going to lead
to an eventual crash.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We occasionally will read from an "incoherent" ptr in the belief that
the clflush hit will be worth it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can read from the current scanout buffer without incurring a visual
tear, so delay the GPU bo exchange until we see a write to the object.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If there are more processors than we ever expect, good! Just use lots of
them, rather than none at all.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the failure in gc move-to-cpu occurs late, i.e. after the function
pointers are updated to point to CPU functions, we need to undo those
changes, i.e. call move-to-gpu for the GC on failure.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we fail to mmap the pixmap when preparing it for use with prime, be
sure to throw away the now lost priv->gpu_bo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Defer the actual wait until the next use of the screen pixmap, and then
if needed replace the GPU bo with an alternative back buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When trying to conserve power, reduce the number of small batches we
emit - trying to maximise GPU efficacy and minimise CPU overhead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the kernel does not preserve the name and driver type when returning
the current CRTC mode, we need to reconstruct those from the EDID mode
when available.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Whenever we reprobe an unchanging output and re-read its EDID, we emit a
useless log message. Previously this was squelched by trying to spot
when an EDID was unchanged through the use of its blob.id, however we
need to do a complete check on the contents in case the kernel returns
us a new EDID with the old id. So make a temporary copy of the current
EDID data and only squelch the log messages if the new EDID is an exact
match.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>