Age | Commit message (Collapse) | Author |
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Since the extended use of move_area_to_gpu for partial migration of
render sources, we exposed the lack of handling of upload caches along
that path.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we skip the migration, we need to avoid using the unitialiased
region. There is no bad consequence as both branches of the if are
no-ops, but it does silence the static checkers and should make the
predicate cheaper.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
"generic" sounds more impressive than "no"
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This reverts commit ddd75d6539dcf692cb76747cd63d1f301180f18a.
This is a WIP patch, not ready for upstream. The danger of mixing topic
branches.
|
|
|
|
One particular buffer type is quite cunning and simultaneously sets both
CPU/GPU as all damaged (the upload buffer) so be aware when making bold
assertions.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The condition that we have a mapped GPU bo iff priv->cpu is only true if
we have a GPU bo at the time of using the CPU -- if we create the GPU bo
during move_to_gpu, then that assertion is bogus.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Be neat and tidy in case we are shutdown but the server is not
regenerated (e.g. a hot-unplug).
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
After syncing the GPU bo for use, that's what we should test as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The clip extents for the stippled BLT missed applying the drawable
offset to the lower-right corner, so inevitably every operation ended up
being clipped.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62618
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Due to long standing ignored bugs in DRI2, we have to accept breakage
in the driver.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62614
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Along the slow path, skip all processing of glyphs that are not visible.
This is important as the slow path handles the per-glyph redirection
case, which is much more expensive.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Fixes sanity checks that we do not leak the flushing status, nor
invoke an operation upon an unflushed bo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the pixmap is not wholly damaged, but still contains the region to be
read, then use userptr (if available).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
i.e. make sure they don't end up in any caches.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Taking into account that we may not do a full synchronisation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The handles of the bo are easier to track through the DBG as they are
more often printed than then their addresses.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Remember all the special cases where we can use a CPU mmap as a
temporary substitute for a GTT mapping.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
There is still a lurking issue, so punt on the optimisation for now.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61628
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As the wakeup handler is called more frequently, we want to avoid any of
the more heavyweight processing. So trim the wakeup handler down to the
check to see if the GPU is idle and so we should immediately flush what
we have currently queued.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Nothing suspicious in this set, just an extra dab of paranoia.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As we may choose to force the stall as we would be doing a read-back in
any event...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
One last minute refactor too far, combining the too if(priv->gpu_bo)
blocks forgot that the first block tried to free gpu_bo...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
By moving the test into the common function for creating a mappable GPU
bo, we can also consider recreating that bo when desirable.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Otherwise we will fail to map it into the GTT. In theory, this should
just result in the same fallback paths, but pushing that knowledge up
further should help us make better decisions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
References: https://bugs.freedesktop.org/show_bug.cgi?id=56608
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Otherwise chaos ensues:
Invalid read of size 8
==8647== at 0x8477BC1: has_offload_slaves.isra.38 (sna_accel.c:14402)
==8647== by 0x84958E7: sna_accel_block_handler (sna_accel.c:13729)
==8647== by 0x164B13: BlockHandler (dixutils.c:387)
==8647== by 0x2B5273: WaitForSomething (WaitFor.c:210)
==8647== by 0x160790: Dispatch (dispatch.c:357)
==8647== by 0x14F549: main (main.c:298)
==8647== Address 0xf3383e8 is 24 bytes inside a block of size 152 free'd
==8647== at 0x4C2BA6C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8647== by 0x2403DF: damageDestroyPixmap (damage.c:1549)
==8647== by 0x1FFD88: XvDestroyPixmap (xvmain.c:372)
==8647== by 0x1FE789: ShmDestroyPixmap (shm.c:273)
==8647== by 0x8507C24: _sna_dri_destroy_buffer (sna_dri.c:448)
==8647== by 0x289986: do_get_buffers (dri2.c:521)
==8647== by 0x289C0F: DRI2GetBuffersWithFormat (dri2.c:690)
==8647== by 0x28B68F: ProcDRI2Dispatch (dri2ext.c:306)
==8647== by 0x160A40: Dispatch (dispatch.c:428)
==8647== by 0x14F549: main (main.c:298)
==8647==
==8647== Invalid read of size 8
==8647== at 0x8477BCA: has_offload_slaves.isra.38 (regionstr.h:74)
==8647== by 0x84958E7: sna_accel_block_handler (sna_accel.c:13729)
==8647== by 0x164B13: BlockHandler (dixutils.c:387)
==8647== by 0x2B5273: WaitForSomething (WaitFor.c:210)
==8647== by 0x160790: Dispatch (dispatch.c:357)
==8647== by 0x14F549: main (main.c:298)
==8647== Address 0xdfdfdfdfdfdfdfe7 is not stack'd, malloc'd or (recently) free'd
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Superficially fixes gimp-2.9
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
References: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1131134
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The Option was untested, and unsurprisingly was broken.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If the GPU bo is a proxy, then it really is a pointer into a upload
buffer for CPU data. In these cases, there should never be any GPU
damage lying around.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This should help catch the error slightly earlier.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Fixes regresion from
commit 09ea1f4402b3bd0e411b90eb5575b3ff066d7356
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Jan 10 16:26:24 2013 +0000
sna: Prefer to use the GPU for copies from SHM onto tiled destinations
As the stalls on IVB 64-bit machines at least greatly offset the
benefits. As those earlier measurements were made on the same IVB
machine but running in 32-bit mode, I need to double-check whether or
not this is another 32-bit peculiarity.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As we must perform the GTT reads anyway, first see if we can copy
directly to the destination.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|