If we are copying over the entire source onto the destination,just copy
across the GPU bo. This is often used for caching images as pixmaps.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We have to be careful to assume bo via exposed are under our full
control, in particular not to assert their state. :(
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
gen2/3 have a restriction that the 3D pipeline cannot render to a pixmap
with a pitch less than 8/16 respectively. Rather than mandating all
pixmaps to be created with a stride greater than 16, fixup the bo for
the rare occasions when it is necessary.
Reported-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43688
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For the long interval events (such as expiring the caches), we do not
need precise timing and so can use a coarse timer to allow the system
to coalesce and reduce wakeup events.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If a pixmap lies around for a couple of minutes not being used, it is
unlikely to be used again in the near future. Reap the GPU buffers of
any of those idle pixmaps (copying to a more compact buffer in system
memory) in order to free up resources for use elsewhere. Any object
that is exposed via DRI is obviously exempt from this reaping.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to avoid inconsistent usage of coherency domains and to avoid
completely unnecessary clflushing during video playback, use the same
buffer allocation and upload functions as the rest of the driver.
Reported-by: Christophe Roland <roll68@gmail.com>
Bugzilla: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=60;bug=651316
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A typo confused left and right, rejecting true vertical edges, and worse
might have incurred false positives.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The operations when setting dpms on should be in the order opposite
of what's done when setting dpms off.
This is because of potentially conflicting effects:
~ drmModeConnectoSetProperty() enables/disables the backlight driver.
Some backlight drivers such as intel_backlight set the backlight to 0
when disabled and to max when enabled.
~ intel_output_dpms_backlight() saves the backlight value when turning
DPMS off and restores it when turning DPMS on.
Here's the current order of operations:
xset dpms force off (backlight is nonzero)
drmModeConnectoSetProperty(DPMSModeOff)
kernel: disable backlight, backlight=0
intel_output_dpms_backlight(DPMSModeOff)
save backlight value (0) <-- it has been set to 0 by kernel
set backlight to 0
xset dpms force on
drmModeConnectoSetProperty(DPMSModeOn)
kernel: enable backlight, backlight=max
intel_output_dpms_backlight(DPMSModeOn)
set backlight to saved value (0)
The correct way to do this would be to reverse the operations during
xset dpms force off:
intel_output_dpms_backlight(DPMSModeOff)
save backlight value (nonzero)
set backlight to 0
drmModeConnectoSetProperty(DPMSModeOff)
kernel: enable backlight, backlight=0
This restores the saved nonzero backlight value during the force on.
Signed-off-by: Simon Que <sque@chromium.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A partial buffer is considered finished upon the next batch submission,
so one needs to be careful that it is completely written to before such
an event is triggered. move-to-cpu is such a trigger as demonstrated by
the picture fixup routine for handling convolution filters.
Reported-by: Victor Machado <machado.prx@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43607
Signed-off-by: Chris Wilson <ickle@crestline.(none)>
Otherwise we may exhaust the per-process vma limit and cause
applications to stop rendering and eventually crash the X server.
Will only work in conjunction with a new libdrm (2.4.28) and commit
c549a77c (intel: Unmap buffers during drm_intel_gem_bo_unmap)
in particular.
Reported-by: nobled@dreamwidth.org
References: https://bugs.freedesktop.org/show_bug.cgi?id=43075
References: https://bugs.freedesktop.org/show_bug.cgi?id=40066
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we never use these with a depth nor attach them to scanout, we can
safely relax the multiple-of-64 byte pitch restriction. In the unlikely
event that we do need A8 surfaces with depthbuffers, this is broken...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The basis for the constraints are what we can map into the aperture for
direct writing with the CPU, so use the size of the mappable region as
opposed to the size of the total GTT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Benchmarking on the current code base, says this is now a win. A
reversal of older benchmarks, so expect further tuning.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The goal of the optimisation is to discard the GPU bo early, so we
can skip the extra damage reduction if there is no gpu bo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We want to avoid the condition of reducing the tiling mode (when reusing
an active untiled buffer in preference to creating a new) for a wide buffer
when doing will force a TLB miss on each sample.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Simon Que