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>
It is valid for the cpu_bo to be NULL, as we may be choosing to free the
large shadow pixel buffer instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The likelihood of an untiled mapping of the scanout is slim, except for
gen3 with large desktops, and there it should never be in the CPU
domain...
The issue is that we may perform an operation "inplace", yet incoherent
with the display engine, and never flush the CPU cache, resulting in
render corruption. In theory at least!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we may end up holding onto and releasing the Screen pixmap last, we
may also be responsible for flushing the last reference to the scanout.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These were added to track down some corruption, but the assertions
themselves are incorrect, just very rare. The upload buffer may
genuinely be cached if we abort the render operation after uploading the
source data, leaving the proxy not coupled to any request.
References: https://bugs.freedesktop.org/show_bug.cgi?id=48400
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we need to make sure that we do invalidate the caches appropriately
on reuse. Mildly paranoid, but strictly required by the spec.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Even if we try to avoid treating an upload buffer as a real GPU target,
we may still choose to migrate the buffer to the GPU in order to keep
other buffers on the GPU. In that case, we do want to create a real GPU
bo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The upload proxy is a fake buffer that we do not want to render to as
then the damage tracking become extremely confused and the buffer it
self is not optimised for persistent rendering. We assert that we do not
use it as a render target, and this patch adds the check so that we
avoid treating the proxy as a valid target when choosing the render
path.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Be paranoid and check that we own the VT before emitting a scanline
wait. If we attempt to wait on a fb/pipe that we do not own, we may
issue an illegal command and cause a lockup.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we do not fully control these buffers, we cannot truly say when they
are idle, we can only trust that the split between us and the compositor
doesn't lead to much corruption.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
==1401== 7,344 bytes in 34 blocks are possibly lost in loss record 570 of 587
==1401== at 0x4027034: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1401== by 0x8BE5150: drm_intel_gem_bo_alloc_internal (intel_bufmgr_gem.c:689)
==1401== by 0x899FC04: intel_uxa_create_pixmap (intel_uxa.c:1077)
==1401== by 0x89C2C41: uxa_glyphs (uxa-glyphs.c:254)
==1401== by 0x21F05E: damageGlyphs (damage.c:647)
==1401== by 0x218E06: ProcRenderCompositeGlyphs (render.c:1434)
==1401== by 0x15AA40: Dispatch (dispatch.c:439)
==1401== by 0x1499E9: main (main.c:287)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes the tiny, one-off leak:
==1407== 8 bytes in 1 blocks are definitely lost in loss record 48 of 527
==1407== at 0x402894D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1407== by 0x8580BE8: drmMalloc (xf86drm.c:147)
==1407== by 0x8583D54: drmAllocCpy (xf86drmMode.c:73)
==1407== by 0x8585265: drmModeGetPlaneResources (xf86drmMode.c:955)
==1407== by 0x8A1BCE9: sna_video_sprite_setup (sna_video_sprite.c:367)
==1407== by 0x8A1A0A3: sna_video_init (sna_video.c:523)
==1407== by 0x89FD4E0: sna_screen_init (sna_driver.c:935)
==1407== by 0x15AD80: AddScreen (dispatch.c:3909)
==1407== by 0x19A2DB: InitOutput (xf86Init.c:817)
==1407== by 0x14981C: main (main.c:204)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The bo may be considered unmappable due to being bound to outside the
mappable region, which we are attempting to rectify through mapping into
the GTT domain.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson