Now that we aren't flushing after every single rectangle, we can strive
for a little efficiency.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we may trigger a flush and a retire when searching for a vertex
buffer for the new vertices, we need to be careful to decouple the
destroyed vbo in order to avoid a use-after-free when inspecting the
state.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A few callers of kgem_bo_is_mappable operate on freed bo, and so need to
avoid the assert(bo->refcnt).
References: https://bugs.freedesktop.org/show_bug.cgi?id=47597
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we transfer the pixmap to the GPU to use as a render source, presume
that we will not need to then touch the local copy (at least for a
while) and so return that memory to the system.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Once upon a time this was used to hide a compiler warning about a
pointer mismatch, now the compiler still warns about the cast, making
the indirect moot.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As gen4 requires the per-rectangle vertex flush, emitting spans on the
GPU is inefficient and so we prefer to composite the mask instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes a regression from
commit 0be1d96471
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Sep 11 21:48:24 2012 +0100
sna: Use inplace X tiling for LLC uploads
which introduced the ability to swizzle into CPU maps, but also
convinced the xorg path to the same - which for large images blows up.
Reported-by: Michael Laß <bevan@bi-co.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57031
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
CopyRegion() also needs to check for stale bo in case the pixmap
dimensions have changed size and so may cause out-of-bounds read/writes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the screen has been reconfigured and the DRI client tries to swap the
old buffers (having not processed the invalidate event and retrieved the
current names), quietly drop the request. If we try to obey the request,
we will end up attaching a back buffer that is the wrong size to the
scanout...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
==25902== Invalid read of size 4
==25902== at 0x4980E13: _list_del (intel_list.h:218)
==25902== by 0x4980EAB: list_del (intel_list.h:240)
==25902== by 0x4981F4B: free_list (sna_damage.c:403)
==25902== by 0x4985131: __sna_damage_destroy (sna_damage.c:1467)
==25902== by 0x49A5276: sna_render_composite_redirect_done (sna_render.c:1921)
==25902== by 0x49C68FC: gen2_render_composite_done (gen2_render.c:1136)
==25902== by 0x497F90F: sna_composite (sna_composite.c:567)
==25902== by 0x4994725: glyphs_via_mask (sna_glyphs.c:1139)
==25902== by 0x4995FB7: sna_glyphs (sna_glyphs.c:1688)
==25902== by 0x8150EB4: ??? (in /usr/bin/Xorg)
==25902== by 0x813CA38: CompositeGlyphs (in /usr/bin/Xorg)
==25902== by 0x8146DE1: ??? (in /usr/bin/Xorg)
==25902== Address 0x7c079ac2 is not stack'd, malloc'd or (recently) free'd
Reported-by: bonbons67@internet.lu
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56785
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
==25902== Use of uninitialised value of size 4
==25902== at 0x423098E: _itoa_word (_itoa.c:196)
==25902== by 0x4233F7F: vfprintf (vfprintf.c:1602)
==25902== by 0x42FAFAD: __vsnprintf_chk (vsnprintf_chk.c:65)
==25902== by 0x81DBE8E: Xvscnprintf (in /usr/bin/Xorg)
==25902== by 0x81DC8FB: LogVMessageVerb (in /usr/bin/Xorg)
==25902== by 0x81DCA62: LogVWrite (in /usr/bin/Xorg)
==25902== by 0x81DCA9B: VErrorF (in /usr/bin/Xorg)
==25902== by 0x81DC333: ErrorF (in /usr/bin/Xorg)
==25902== by 0x49B2FA8: trapezoid_span_inplace__x8r8g8b8 (sna_trapezoids.c:5069)
==25902== by 0x49B3407: trapezoid_span_inplace (sna_trapezoids.c:5166)
==25902== by 0x49B4C96: sna_composite_trapezoids (sna_trapezoids.c:5619)
Reported-by: bonbons67@internet.lu
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56785
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is to prevent falling in the trap of the rendering being delayed
until the next client renders some new content.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
==29553== Invalid read of size 4
==29553== at 0x4980E1B: _list_del (intel_list.h:218)
==29553== by 0x4980EB3: list_del (intel_list.h:240)
==29553== by 0x4981F53: free_list (sna_damage.c:403)
==29553== by 0x4985139: __sna_damage_destroy (sna_damage.c:1467)
==29553== by 0x49A527E: sna_render_composite_redirect_done (sna_render.c:1921)
==29553== by 0x49C6904: gen2_render_composite_done (gen2_render.c:1136)
==29553== by 0x497F917: sna_composite (sna_composite.c:567)
==29553== by 0x8150C41: ??? (in /usr/bin/Xorg)
==29553== by 0x8142F13: CompositePicture (in /usr/bin/Xorg)
==29553== by 0x8145F58: ??? (in /usr/bin/Xorg)
==29553== by 0x81436F2: ??? (in /usr/bin/Xorg)
==29553== by 0x807965C: ??? (in /usr/bin/Xorg)
==29553== Address 0x9407e188 is not stack'd, malloc'd or (recently) free'd
Reported-by: bonbons67@internet.lu
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56785
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
==29553== Use of uninitialised value of size 4
==29553== at 0x4230964: _itoa_word (_itoa.c:195)
==29553== by 0x4233F7F: vfprintf (vfprintf.c:1602)
==29553== by 0x42FAFAD: __vsnprintf_chk (vsnprintf_chk.c:65)
==29553== by 0x81DBE8E: Xvscnprintf (in /usr/bin/Xorg)
==29553== by 0x81DC8FB: LogVMessageVerb (in /usr/bin/Xorg)
==29553== by 0x81DCA62: LogVWrite (in /usr/bin/Xorg)
==29553== by 0x81DCA9B: VErrorF (in /usr/bin/Xorg)
==29553== by 0x81DC333: ErrorF (in /usr/bin/Xorg)
==29553== by 0x49434F0: kgem_create_buffer (kgem.c:4887)
==29553== by 0x4943B09: kgem_create_buffer_2d (kgem.c:4969)
==29553== by 0x4943E19: kgem_upload_source_image (kgem.c:5021)
==29553== by 0x49A0567: upload (sna_render.c:505)
==29553==
Reported-by: bonbons67@internet.lu
References: https://bugs.freedesktop.org/show_bug.cgi?id=56785
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On review (read triggering BUGs), we do need to supply the domain tracking
of the buffers that is being replaced from the relocation path.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we bypass the relocation processing, we also then bypass the
pending-write analysis, so we need to supply those to the kernel
ourselves (to maintain gpu-cpu coherency).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Eric Anholt