Although we are ordered wrt to the client, there is no point allowing
the client to continue submitting rendering and eventually blocking
whilst we are still waiting for the previous frame to be shown.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Not only is the pixmap->flush flag shared, but so is the lower level
gpu_bo->flush flag, so further to
commit 19d1e4ee19
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Jun 11 13:43:10 2015 +0100
sna/dri2: Be wary of interactions with DRI3 and sna_pixmap->flush
we need to be more careful when asserting the state of gpu_bo->flush
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We still only keep it alive whilst the event chain is in progress, but
moving the cache onto the window allows us to reuse it easily for triple
buffer window swaps as well as full screen flips.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When the trapezoid is rendering to a surface larger than the 3D pipe can
handle, we split it into tiles. However, the code to do so insisted on
passing along the wrong pointer and consequently crashed.
Based on the patch by Carl Michal.
Reported-by: Carl Michal <michal@physics.ubc.ca>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90940
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to perform swap elision for windows, we defer the blit until
the next vblank and then do whatever was the last buffer to be presented
by the client. Whilst that copy is pending, in the same manner as a
pending flip, we cannot hand that buffer back to the client for use (or
else they will render over top of it before we copy from it, or even
worse we copy from it in the middle of rendering).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since both DRI2 and DRI3 manipulate the sna_pixmap->flush flag, we have
to relaxation assertions that it is wholly owned by DRI2.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We know Present is sending garbage msc into the wait_vblank, so just
warn about the error so that we do not prevent usage of --enable-debug
due to somebody else's bug.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For PRIME bo, we need to use uncached render targets so that any writes
are flushed out to main memory where they can be immediately read by a
PCI device. For simplicity, we just request that PRIME bo be also
SCANOUTs as that ensures that they will be created with the right
attributes for coherent main memory.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the slave may use the ProcessPending damage callback to do its own
copying, we need to flush before.
Reported-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the source is only being exported for reading, we can skip adding it
to the flush list only to perform a no-op.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the case of an exported pixmap, e.g. with DRI3, it is possible for
the client to render into the pixmap whilst we are unaware. To serialise
the xserver and the client, we flush all operations on exported pixmaps
before talking to the client. In the case of COW however, we did not
flush the copy-on-write when transferring control to the client, and
thereby we could capture the modified contents.
Bugzilla: https://bugs.kde.org/show_bug.cgi?id=340202
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90836
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
commit d1bf75f155
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Jun 1 08:56:43 2015 +0000
sna: Compilation fixes for stable distros
caused an apparent regression by using the wrong ring for detecting
whether we could program the BCS tiling registers.
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
commit d1bf75f155
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Jun 1 08:56:43 2015 +0000
sna: Compilation fixes for stable distros
set the flag incorrectly - only future Xorg will do the damage
application itself.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When using a fixed mode, e.g. a Display without RandR support like
Xnest, we have to remember to hook up the connection during
recofiguration of VIRTUAL outputs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we find that the kernel has more active CRTC than we successfully
enable, something is amiss and more importantly we are leaving an
existing active CRTC blank. As a failsafe, if we detect this, fallback
to doing a full probe for the initial configuration.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
Chris Wilson
Damien Lespiau
Sedat Dilek