Age | Commit message (Collapse) | Author |
|
We currently hack TearFree/DRI2/swcursor to avoid recursion from inside
the SwapBuffers to handle the swcursor. This has the issue of a trailing
cursor on the boundary of the DRI2 drawable, but prevents the explosion
from swapping TearFree buffers from within the TearFree handler (i.e.
recursion). This only has to apply to the damage processing before the
swap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
References: https://bugs.freedesktop.org/show_bug.cgi?id=96695
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the pixmap on a drawable changes between swap events, just queue a
normal vblank event rather than chaining up.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Whilst waiting for the previous blit to complete, if we fail to queue
the vblank to wake up on the next frame, block before replying the blit
is complete.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the client sends an out-of-date swap request, first make sure that we
don't cause an error by chasing a NULL CRTC and secondly force them to
wait for a whole vblank before the next swap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The pending back buffer is only the pending copy, the actual info->back
stores the client's view of the current back buffer which may be more
recent than the pending copy. So store the current back buffer, swap in
the pending to do the normal swap, then free the resultant back (which
may have been exchanged with the front), before restoring the client's
current back buffer.
References: https://bugs.freedesktop.org/show_bug.cgi?id=95200
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the kernel can't accept our tiling requirements, don't fret until we
actually need that fence! If we do, then we either stop tiling with the
buffer or we use another.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
After releasing the list, we need to mark it as freed.
Oversight from commit a11cbb6954f08edd0d8fb5eeca1debb289fdb9af
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Mar 15 21:11:48 2016 +0000
sna/dri2: Cancel all pending events when the window is resized
which reused the code for destroying the window (where priv->chain will
not be accessed again afterwards).
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When a Window is resized, a new Pixmap is attached to the Window and the
DRI2 buffers invalidated. However, the client may have requested a swap
before it is notified of the resize and so we have to discard the stale
swap. In doing so, we do not want to start a swap chain as it references
the wrong frontbuffer and causes dire confusion when we start swapping
for real.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70461#c131
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Kill the events early for simplicity.
References: https://bugs.freedesktop.org/show_bug.cgi?id=70461#c138
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Ensure that we don't try and double-free the decoupled vblank event by
checking whether it is still pending first.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When we do a partial flip (one CRTC of many) we install a fake
frontbuffer for the window. This needs to be included in the
active-scanout tracking like a normal frontbuffer to avoid being
recycled too early.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the root window's pixmap is changed (e.g. to resizing the
framebuffer) then an outstanding flip becomes invalid. The invalid flip
is marked as having a stale front, and that triggers an assertion if the
user then tries to schedule flip before the pending flip event is
processed.
References: https://bugs.freedesktop.org/show_bug.cgi?id=9425
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we fail to queue a flip for a CRTC, we attempt to restore the
original mode. However, if the failure is on a second CRTC, the queued
flip on the first will still complete causing us to process the event
twice.
References: https://bugs.freedesktop.org/show_bug.cgi?id=94250
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Silence a valgrind warning, though it should have no runtime impace.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the Drawable is gone, we cannot send it a frame-complete signal, and
in particular we cannot continue the pending flip-chain.
References: https://bugs.freedesktop.org/show_bug.cgi?id=93844
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Before sending the frame swap complete signal after a FLIP, make sure
the client didn't die in the meantime.
Reported-by: Diego Viola <diego.viola@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=93844
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The main motivation is try and isolate from an upcoming API change in
busy-ioctl, but is also based on the observation that we now only care
about write-synchronisation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Since we need the drawable to call DRI2SwapComplete/DRI2WakeClient, if
the window is destroyed that becomes inoperable (as we are called late
in the chain). Let's hope the client isn't blocked.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When we do the exchange for the next swap, we should emit any pending
completion signal for the previous buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
From the previous commit, we have to check for NULL before the
dereference.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Fixes regression from
commit 8d9e496670f48b4eec64dfe1bcedb49793cf3073
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jul 22 11:14:01 2015 +0100
sna/dri2: Take over the placeholder vblank
After noting the fence was complete, we would clear it. But I forgot
that we actually held a reference on to it, and so we would leak the 64k
batch, and starve the system of available memory in about 18 minutes of
SwapBuffers.
Reported-by: Arkadiusz Miskiewicz <arekm@maven.pl>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92911
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Simply sedding the name over to the new variable was insufficient as it
is now the logical opposite. Fixes
commit 64dbcdd4de1fe1941196265d054272d7d93e5d59
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Nov 10 09:56:07 2015 +0000
sna/dri2: Add a specific recursion indicator for TearFree/DRI2
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Avoid conflating the DRI3/Present flag for controlling TearFree by
adding a separate flag to indicate when we are waiting inside the
TearFree shadow handler to avoid recursion in DRI2.
Reported-by: Andreas Reis <andreas.reis@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92873
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
With the introduction of a new SwapEvent that may trigger a copy, we
need to add another check for recursion from a TearFree flip event.
References: https://bugs.freedesktop.org/show_bug.cgi?id=92751#c14
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Some time past, we switched to a seperate boolean to mark when the
shadow is no longer accessible due to recursion - but I missed an
important check inside the vblank handler.
Reported-by: Joe Peterson <joe@wildlava.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92751#c5
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In order to catch transitions between SwapInterval 0 and 1 in the middle
of a flip sequence, we need to reset our swap_limit every time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Once again I tried to add an event to a pixmap, but only Windows carry
the CRTC tracking information. Stop it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Even though the kernel reports and error and we skip the queuing, we
have information to avoid the roundtrip through the kernel.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
On a headless or hosted system, we do not have any CRTC on which to
report or queue the vblank. Reporting a BadDrawable is evil (as clients
never expect the error) but is better than crashing the Xserver.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Along the blit swap path, we expect the buffer to not be scanout
compatible and not have the same pitch as the front buffer. The reuse
logic failed to take this into account!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Otherwise we raise assertions about trying to attach events to an
illegal Window.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As the window may be reparented during its swap lifetime, we may be able
to recreate the backbuffer ready for flipping next swap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Since the DRI2BufferPtr destruction may be delayed, by the time we do
free it, the state may no longer be accurate. (At this level at least,
there is a later assertion to the same regard just as we think we are
releasing the buffer.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
With the rigamorale of assertions, using the vblank is no longer
trivial.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This so that we permanently exclude the active front buffer from the set
of triple buffer replacements.
References: https://bugs.freedesktop.org/show_bug.cgi?id=91658
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Down one particular patch (overlapping render copies) the
scratch.pScreen is dereferenced (to create a temporary Pixmap). Ensure
that we populate it before hand.
References: https://bugs.freedesktop.org/show_bug.cgi?id=91658
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The local was only used in debug builds, so remove it to squash the
compiler warning.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
To ease tracking of the next swap, stash it on the event (which is then
reused) rather than the back buffer (which changes frequently).
In addition, add debug flags and assertions to track event stages (such
as making sure we do not decouple/free an event that we have sent a
signal back to the client).
References: https://bugs.freedesktop.org/show_bug.cgi?id=91658
References: https://bugs.freedesktop.org/show_bug.cgi?id=70461
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Third time lucky at getting the pending copy swap with the real back
correct?
References: https://bugs.freedesktop.org/show_bug.cgi?id=70461
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
References: https://bugs.freedesktop.org/show_bug.cgi?id=91658
References: https://bugs.freedesktop.org/show_bug.cgi?id=70461
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we don't control the vblank for the window, we cannot use the vblank
signal as it ends up being queued as well.
References: https://bugs.freedesktop.org/show_bug.cgi?id=91658
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
A side effect of commit 4cea8037984c3d5e171be22710384f66660ca4c6
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sat Aug 8 22:10:20 2015 +0100
sna/dri2: Restore caching of fullscreen triple buffers
was that we discovered that we had been inserting the buffer into the
cache list multiple times.
Reported-by: Dan Doel <dan.doel@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=91658#c5
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the DRI2 copy ends up on the CPU, then we will not have a GPU
request for the operation.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If a client dies with a pending flip, we have to complete it so that the
scanout matches the frontbuffer again. This requires one last flip
following the client disapparance.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|