If we have no fence, we then try to discard the tiling. However, the
change_tiling routine assumes that it is only called when a change is
actually required. Make it so for dri2.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As a consequence of using GPU swizzling without telling the kernel is
that we must disable GTT access -- especially if we already have a
linear mmapping.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On gen4+, we no longer need to setup a fence for tiled operations and so
can program the GPU irrespective of the kernel tiled settings. However,
this means that we then cannot access the object through a GTT mmapping
(as we have no fence to do detiling) and nor can we use a WC mmap as the
swizzle is unknown.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We have to ignore the return value of the pitch for untiled 2D surfaces
(since the kernel clears the tiling stride parameter).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since the kernel can silently change the tiling on the object
irrespectie of the ioctl's request, we have to double check and remove
any such invalid object from our lists.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the swizzling is unknown, the SET_TILING ioctl silently converts the
request back to I915_TILING_NONE. In order to detect this, we need to
double check the ioctl parameters.
References: https://bugs.freedesktop.org/show_bug.cgi?id=90725#c21
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we disable a CRTC, mark it as such and send an XRR event so that
userspace can do any recovery, and so that hopefully xrandr remains
consistent.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since sna_set_desired_mode() always returns true, we can make it void
and remove some unreachable code.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The preference given multiple rings is to the previous writer, or if
none, to the render ring if active.
References: https://bugs.freedesktop.org/show_bug.cgi?id=90671
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In case of error, we try to free up memory before trying again. This
involves callbacks into higher level code - but if we fail early, we
will not have those hooks installed. Set no-ops stubs early to prevent
untimely crashes.
References: https://bugs.freedesktop.org/show_bug.cgi?id=90622#c1
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to reset the SW cursor, we need to call xf86CursorSetCursor.
However, the parameters we need to call SetCursor with are not exposed
we need to be a little tricky and call a pair of functions that will
save and then restore the cursor.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we cannot control the HW cursor, flag it as invalid and enable the SW
cursor next time. The flag will remain set until the next modeset and we
then try the HW cursor again.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Mostly for completeness, though it is still remotely possibly for the
dst pointer to raise a SIGBUS (just less likely since it is not a i915
bo).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Originally this was inplace so that we wouldn't simply migrate the
target away from the GPU whenever we inspected results. That is no
longer a problem and so we can speed up the tests by skipping the
temporary.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We shouldn't just discard the mask if the user requests that we render
the glyphs through a low bitdepth mask - and in doing so we should also
be careful not to improve the bitdepth of that mask (since we don't take
into account the extra quantisation desired).
Testcase: render-glyphs
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
All pointer access into a mmap() arena should be wrapped by sigtrap, in
case the kernel generates a SIGBUS (oom, eio, bugs, etc). Add a couple
more missing annotations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When we mark the GPU as wedge and disable acceleration, always check if
there is a GPU error state and warn if so - it is increasingly rare to
get a pure EIO from throttling thereby circumventing the current error
state checker.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Anytime we access a mmap() we need to be prepared for the kernel to send
us a SIGBUS, but we were missing a few sigtraps around calls to
pixman_fill and pixman_blt.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These are primarily to serve to detect when we expect to see corruption
as a result of a badly timed EIO rather than fatal, so downgrade the
assertion to a warn.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We only need a single copy of the cursor image, from which we can create
all the cloned cursors.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With a MST topology change, we can find outputs may disappear. We offered
a choice as to whether to simply disable them or completely remove them
from the listing of available outputs. However, clients never expected
that their operation on any output could trigger a BadID XError (or that
there is anyway to prevent race conditions). As such an option was made to
disable by default, but allow testing complete removal. Now the RandR
protocol has been clarified such that XID assigned to outputs are now
permanent, as such the option breaks the spec, so drop it.
See randrproto commit 895ee5264524c7c239ee4ef5e39c4e295323fb51
Author: Dave Airlie <airlied@redhat.com>
Date: Wed Apr 22 10:58:18 2015 +1000
randrproto: clarify output XID lifetimes.
This just makes a note that randr won't make outputs disappear
dynamically.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Backlight helper PID is set to -1 by default, if for some reason it's
not set, we may end up with waitpid(-1, ...) which will hang forever.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90230
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
A couple of stray set-purgeable points were causing eventual assertions
that we didn't try and set-purgeable twice.
Minor regression from
commit 73ae4197d6
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Apr 24 14:36:50 2015 +0100
sna: Defer marking cache objects purgeable
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
../../../src/uxa/intel_driver.c: At top level:
../../../src/uxa/intel_driver.c:769:1: error: unknown type name 'bool'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
gcc generates an error at build time because it fails to inline some
functions:
blt.c: In function 'affine_blt':
blt.c:980:1: error: inlining failed in call to always_inline
'bilinear_weight': optimization level attribute mismatch
bilinear_weight(pixman_fixed_t x)
blt.c:1164:7: error: called from here
fy = bilinear_weight(y1);
^
blt.c:980:1: error: inlining failed in call to always_inline
'bilinear_weight': optimization level attribute mismatch
bilinear_weight(pixman_fixed_t x)
blt.c:1163:7: error: called from here
fx = bilinear_weight(x1);
^
blt.c:989:1: error: inlining failed in call to always_inline
'bilinear_interpolation': optimization level attribute mismatch
bilinear_interpolation(uint32_t tl, uint32_t tr,
^
blt.c:1207:11: error: called from here
b[i] = bilinear_interpolation(tl, tr, bl, br, fx, fy);
^
Do not force inlining of these functions and let the compiler decide to
avoid the compilation failure.
v2: fix up the other two force_inlines whilst we are here
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
In a couple of the copy paths, src/dst parameters were reversed,
inverting the direction of the tiling flags.
Reported-by: Andy Furniss <adf.lists@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90138
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bspec says it is an override for the source format, irrespective of
the tiling bit supplied in the command packet. So we need to apply the
FLUSH+LRI more often.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Somewhere, somehow the first glyph character upload into the Y-tiled
glyph cache is corrupt since
commit 75d8776247
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Apr 17 10:29:28 2015 +0100
sna: Enable blitting with Y-tiled surfaces
I have not spotted whether it is a missing magic bit or a bad GTT path,
but ideally we don't want to switch to BLT along that path anyway (since
we are in the middle of rendering with the other engine).
Reported-by: Andy Furniss <adf.lists@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=90138
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Olivier Fourdan