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>
Adam Jackson notes that what appeared to be my paranoid ramblings in SNA
actually served a purpose - it prevents a server crash following
server regen if an indirect client happened to be running at the time
(e.g. LIBGL_INDIRECT_ALWAYS=1 glxgears).
Reported-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since RandR itself is disabled if Xinerama is enabled, for example with
ZaphodHeads, calling RRGetInfo() upon a hotplug event generates an
assertion.
Reported-by: Stephen Liang <inteldriver@angrywalls.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55260
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Damage is processed in two phases, with the actual Damage being appended
before the operation is performed so that a copy can be made before
modification (e.g. software cursors).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On gen6+, bo are expected to be LLC by default. However, as using the bo
for the scanout causes it to be moved into the uncached domain, this
assumption is then false and we should release the bo back to the system
rather than spread the uncached buffers around. The most common
allocator of scanouts is for pageflipping which are already non-reusable
due to the DRI2 export, so there should actually be little impact.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When we return NULL from sna_drawable_use_bo(), the expectation is that
the damage pointer is also NULL. However, one SHM path leaked.
References: https://bugs.freedesktop.org/show_bug.cgi?id=56180
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson