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>
As we reuse the input parameter 'box' to hold the array of boxes that
need to be migrated, we need to be careful that we do not later confuse
it with the original input parameter. Otherwise,
==1315== Invalid read of size 2
==1315== at 0x928B091: box_inplace (sna.h:506)
==1315== by 0x9292278: sna_pixmap_move_area_to_gpu (sna_accel.c:2554)
==1315== by 0x9292C14: sna_drawable_use_bo (sna_accel.c:2774)
==1315== by 0x9356C01: gen7_composite_set_target (gen7_render.c:2448)
==1315== by 0x9357AA2: gen7_render_composite (gen7_render.c:2800)
==1315== by 0x92DB12E: glyphs_to_dst (sna_glyphs.c:552)
==1315== by 0x92DEA8D: sna_glyphs (sna_glyphs.c:1664)
==1315== by 0x4F920E: damageGlyphs (in /tmp/Xorg)
==1315== by 0x4F2FF6: ProcRenderCompositeGlyphs (in /tmp/Xorg)
==1315== by 0x437260: Dispatch (in /tmp/Xorg)
==1315== by 0x426466: main (in /tmp/Xorg)
==1315== Address 0xd637054 is 20 bytes inside a block of size 208,464 free'd
==1315== at 0x4C2A2FC: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==1315== by 0x92CCFCD: __sna_damage_destroy (sna_damage.c:1469)
==1315== by 0x928AD74: sna_damage_destroy (sna_damage.h:284)
==1315== by 0x9291CB2: sna_pixmap_move_area_to_gpu (sna_accel.c:2470)
==1315== by 0x9292C14: sna_drawable_use_bo (sna_accel.c:2774)
==1315== by 0x9356C01: gen7_composite_set_target (gen7_render.c:2448)
==1315== by 0x9357AA2: gen7_render_composite (gen7_render.c:2800)
==1315== by 0x92DB12E: glyphs_to_dst (sna_glyphs.c:552)
==1315== by 0x92DEA8D: sna_glyphs (sna_glyphs.c:1664)
==1315== by 0x4F920E: damageGlyphs (in /tmp/Xorg)
==1315== by 0x4F2FF6: ProcRenderCompositeGlyphs (in /tmp/Xorg)
==1315== by 0x437260: Dispatch (in /tmp/Xorg)
Reported-by: Matti Ruohonen <kiesus@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56591
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There exists a race with plymouthd that can cause the drm device to
reject us as the rightful master, and so cause X to fail to load. Try
waiting for a couple of seconds for whatever it was to close before
giving in.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>