Age | Commit message (Collapse) | Author |
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Baby step. We first take advantage of TearFree to allow us to redirect a
single CRTC to the DRI2 frontbuffer and so allow a fullscreen game
covering a single monitor to avoid expensive blits when running in a
multi-monitor setup.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This was disabled in
commit 9f4f855ba37966fb91d31e9081d03cf72affb154
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon May 26 07:06:18 2014 +0100
sna: Implicit release of upload buffers considered bad
as retiring the buffers during the command setup could free one of the
earlier bo used in the command. But discarding the snooped bo could
still be advantageous. So restore the automatic discard of upload
proxies, but make sure we only do between operations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matti Hämäläinen <ccr@tnsp.org>
|
|
And double check after recreating the new GPU bo that is still mappable.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
With a shadow, we may never attach a GPU bo to the frontbuffer, so be
careful when checking the scanout not to dereference that NULL pointer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
It is far easily to pass the PixmapPtr into the function and have it
pluck out the width and height than do so in all callers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When we discard a GPU bo, we need to make sure that the remaining
content is marked as only accessible via the CPU shadow pointer.
Regression from commit 65301412ecf2d55ab55a2d7faeaa048d4ee8b1d0
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sat May 17 20:59:38 2014 +0100
sna: Discard active GPU buffers before uploading into them
Reported-by: Jan Alexander Steffens <jan.steffens@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79517
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The primary benefit of this is avoid the extra blit when using a
compositor and instead propagate the compositor flip on the frontbuffer
to the scanout, or equivalently allows a fullscreen game to flip onto
the scanout without intervention by TearFree.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In commit 961139f5878572ebea268a0bbf47caf05af9093f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri May 30 09:45:15 2014 +0100
sna: Use manual detiling for downloads
the code for deciding when to use the GPU was refactored into a new
function that also performed the transfer, but failed to notice the
early return.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we can CPU mmap the GPU bo, prefer to do so for migration to the CPU
as this saves an extra serialisation step.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Currently upload buffers are automatically decoupled when the buffer is
retired. As retiring can happen during command setup after we have
selected which bo to render with, this can free the bo we plan to use.
Which is bad.
Instead of making the release of upload buffers automatic, we manually
check whether the buffer is idle before use as a source to consider
scrapping it and replacing it with a real GPU bo. This is likely to keep
upload buffers alive for longer (limiting reuse between Pixmaps but
making reuse of the buffer within a Pixmap more likely) which is both
good and bad. (Good - may improve the content cache, bad - may increase
the amount of memory used by upload buffers for arbitrary long periods.)
Reported-by: Matti Hämäläinen <ccr@tnsp.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79238
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This saves us from trying to optimise for an operation that cannot
happen as we cannot replace the destination buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Avoid busy-spinning waiting for the cache to expire after a failure. Try
to free up any overdue expiration, then if we still fail, we free the
entire cache. Currently, it would spin over the expiration until all
items were overdue and then freed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
And add a new DBG option to disable partial-cpu migrations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we are overwriting part of the framebuffer, we know we do not need to
read that portion back from the scanout.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Allow us to write into a GPU bo without any pending CPU damage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We can update the priv->cpu flag more accurately by accounting for the
early exits for the INPLACE accessors.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
On older architectures, we can only do the inplace upload into a GPU bo
into a new unused bo (that is still in the GPU domain).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
References: https://bugs.freedesktop.org/show_bug.cgi?id=77436
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the upload is clipped, we do not want to apply the WHOLE migration hints.
References: https://bugs.freedesktop.org/show_bug.cgi?id=77178
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This help with the continuing saga of
commit 1de1104064b5898cbed37e836901694a381c1266 [2.99.911]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Feb 21 22:43:04 2014 +0000
sna: Use a hint to do whole image uploads inplace
References: https://bugs.freedesktop.org/show_bug.cgi?id=77178
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
References: https://bugs.freedesktop.org/show_bug.cgi?id=77178
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
References: https://bugs.freedesktop.org/show_bug.cgi?id=77074
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Once again, we must be careful when promoting from a region to whole
pixmap migration that we do not discard required damage.
Fixes regression from
commit 27ac9f574f65cbd535751c925e9b2e2d7c8a6b3a [2.99.911]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Feb 27 08:33:52 2014 +0000
sna: Avoid promoting region-to-whole migration and discarding damage
Reported-by: gedgon@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77063
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The assertion was checking that the invalid condition was true, rather
than that it never happened. Oops.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the pixmap is already partially on the GPU, and the next operation
touches the entire pixmap, promote that operation back to the whole GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Otherwise we ignore the purpose of applying the clip!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Normally, we try to render into the CPU bo of a SHM pixmap. However, under
the right circumstances we may try to do a series of rendering into the
GPU bo and then copy it back to the CPU bo. In that case, we need to be
sure to mark the pixmap as requiring the flush.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|