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>
As the fast paths only setup state upfront, we were missing the state
changes required between dash-on/off. Take advantage of that each pixel
is only drawn once to batch the state changes and run the
miZeroDashLines twice.
A future task would be to use a custom line drawing routine...
Fixes regression from ec1267df74.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For a vmapped upload buffer, we need to notify the kernel (and thereby
the GPU) to invalidate the sampler and flush its caches when we reuse an
idle buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to use the full 32-bits of mmap address space on small
platforms we need to use mmap64().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
sna_accel.c: In function 'sna_pixmap_move_area_to_gpu':
sna_accel.c:1751:12: warning: declaration of 'flags' shadows a parameter
[-Wshadow]
sna_accel.c:1731:72: warning: shadowed declaration is here [-Wshadow]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And mark it as currently in no domain afterwards, so that if we reuse
it, it will be appropriately moved later.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
To avoid accumulating the write offset for wide spans, we need to reset
the destination pointer between spans.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48332
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In particular the glyph routines require the composite setup to
reinitialise state between glyph runs. This affects anything trying to
use glyphs without a mask with a gradient source, for example.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Otherwise we do not detect gradients that start from white!
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48407
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Caught by the addition of the assertion.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=47597
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the required temporary mask is larger than the 3D pipeline can
handle, just render to a CPU buffer rather than redirect every glyph
composition.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson