After attaching the bo to the scanout, mark it as retired in order to
update its domains so that the assertion during retirement later is
correct.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49526
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Should fix regression from fcccc5528 (sna: Improve handling of inplace
IO for large transfers) whereby it was aborting the transfer it we need
to remap the buffer for the upload.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49546
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we are now throttling to relieve GTT pressure, it is a benefit to
consistently throttle before blocking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we have some active buffers that we may reuse and old outstanding
requests, throttling before retiring should prevent the CPU from running
away from the GPU and hogging the entire GTT and RAM.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As batch buffers are compacted to fit into the smallest bo, the only
cost is the larger static array allocation (and presumably cache
misses).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The block handler is run after the timers are queried for their
expiration and so if we install a timer in the block hander, we must
set the timeout ourselves.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As timerfd is linux-specific, and OsTimer an OS-agnostic abraction,
replace the former with the later. Arguably this has slightly better
performance characteristics in select-bound loops.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Unlike the fallback for an unhandled depth, we need to ensure that the
pixmaps are mapped to the CPU before calling the fb routines.
Reported-by: Toralf Förster <toralf.foerster@gmx.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49558
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Looks like the assumption for the location of the data is invalid,
allocation failure, perhaps?
References: https://bugs.freedesktop.org/show_bug.cgi?id=47597
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Also fixup a weakness of only tracking scanout with a single bit, as we
used to clear it forcibly after every flip.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than attempt to flatten the chain to the last link, we may need
to hold a reference to the intermediate links in case of batch buffer
submission.
Fixes http://tnsp.org/~ccr/intel-gfx/test.html
Reported-by: Matti Hamalainen <ccr@tnsp.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49436
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the transfer is large enough to obliterate the caches, then it is
preferrable to do it inplace rather than upload a proxy texture and
queue a blit. This helps prevent an inconsistency where one layer
believes the operation should be done inplace only for the IO layer to
perform an indirect upload.
Testing show no significant impact upon the cairo-traces, but it does
prevent x11perf -shmput from exploding.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The underlying cause is still not fixed. It should be possible to use
the much laxer alignment for single-stream linear. Still no idea how I
fail to convince the GPU to drop the depth buffer.
Reported-by: Matti Hamalainen <ccr@tnsp.org>
References: https://bugs.freedesktop.org/show_bug.cgi?id=49391
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson