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>
The shaders treat colours as an argb value, however the clear color is
stored in the pixmap's native format (a8, r5g6b5, x8r8g8b8 etc). So
before using the value of the clear color as a solid we need to convert
it into the a8r8g8b8 format.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48204
Reported-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47308
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson