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>
This provides for using the existing DDX with future DRI drivers which
may break from the traditional names - but only with the help of the
user/packager. This scheme needs to be replaced with a robust mechanism
for driver loading if AIGLX and co are to be kept.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Note that this is worsened, but not caused, by:
commit e1a63de899
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Nov 2 09:10:32 2012 +0000
sna/gen4+: Prefer GPU spans if the destination is active
References: https://bugs.freedesktop.org/show_bug.cgi?id=55500
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Eric Anholt