This adds support for pixmap tracking and scanout of
alternate pixmaps.
v2: do dirty updates after uxa block handler, check if kernel
can flush vmap for us so we don't have to.
Signed-off-by: Dave Airlie <airlied@redhat.com>
If the hw/kernel doesn't support snoopable buffers, then it makes little
sense to search for one, and force a retire in the certainty of not
finding any.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The issue being that, due to the delay, the chained swap would miss its
intended vblank and so cause an unwanted reduction in frame throughput
and increase output latency even further. Since both client and server
have other rate-limiting processes in place, we can forgo the stall here
and still keep the clients in check.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54274
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we may defer the actual release of the pixmap until after completion
of the last shm operation, we need to make sure in that case we mark the
GPU bo as released to prevent a use-after-free.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Otherwise we end up considering the GPU bo as a real target, causing
confusion and failed asserts.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes regression from
commit 96a921487e
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Aug 27 21:50:32 2012 +0100
sna: Track outstanding requests per-ring
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we now may not prefer to use the GPU even if all-damaged and clear,
asserting that if we choose to use the CPU if clear is now bogus.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The subtly is that we need to reset the mode correctly after
submitting the batch which was not handled by kgem_flush(). If we fail
to set the appropriate mode then the next operation will be on a random
ring, which can prove fatal with SandyBridge+.
Reported-by: Reinis Danne <reinis.danne@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to properly track when the GPU is idle, we need to account for
the completion order that may differ on architectures like SandyBridge
with multiple mostly independent rings.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54127
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the code will optimistically convert a request for a GTT mapping into
a CPU mapping if the object is still in the CPU domain, we need to
overrule that in this case where we explicitly want to write directly
into the GTT and furthermore keep the buffer around in an upload cache.
References: https://bugs.freedesktop.org/show_bug.cgi?id=51422
References: https://bugs.freedesktop.org/show_bug.cgi?id=52299
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we will stall in the near future to serialise access with the
ShmPixmap, we may as well stall first and do a simple copy using the
CPU in this highly unlikely scenario.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This helps minimise the stall when syncing with the GPU before sending
the next reply to the Client.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Сковорода Никита Андреевич
Dave Airlie
Dave Airlie