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>
If the pixmap's GPU bo is already allocated with Y, expect Mesa to deal
with it rather than convert to X.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since the first flip may require a fixup, we will only really know with
the second flip whether we can start a flip chain with different tiling.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we receive an error from the pageflip ioctl, we attempt to set the
framebuffer using SETCRTC instead. This is so that we can transition
between pitches and offsets for a CRTC. However, the kernel may reject a
flip also for tiling changes, or for any reason, which we also want to
transparently handle. Rearrange the error message and flip->blit
fallback handling to only do so if we try to flip twice (i.e. after
resetting the CRTC) and we still fail.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Let the read know how to compile dri3info without having to compile the
whole of xf86-video-intel
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since gen6, there has been a magic register bit to change the
interpretation of the tiling mode between X and Y for BLT operations.
With the advent of DRI3 and scanouts supporting Y, enabling support at
last appears interesting, perhapss even by default for non-scanouts?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we treat it as a name we should capitilize each word, but we forgot
that rule (sometimes!) for Broadwell.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
According to BSpec the max number of VS URB entries for CHV is 640.
Based on a patch by Ville Syrjälä.
v2: Start using a GT info block like earlier generations.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [v1]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Use the correct register (Yn_01) with first half of the
Y samples instead of using the register (Yn_23) with the
second half twice when computing the green channel.
Also use the Yn_01 register name instead of Yn for the red
channel as well, just for a bit of extra consistency.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89807
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
If at first you don't succeed, try, try again.
The kernel API is lame and requires a new interface for something that
is designed to be supported through the old interface...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since creating/destroying the mmu_notifier for sync userptr is fairly
expensive, leak the test userptr object to keep it around for the
lifetime of our process.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>