On 06/06/2011 03:10 AM, Chris Wilson wrote:
In order to correctly account for reserving space in the GTT and fences
for a batch buffer, we need to independently track whether the fence is
pinned due to a fenced GPU access in the batch from from whether the
buffer is pinned in the aperture. Currently we count the fenced as
pinned if the buffer has already been seen in the execbuffer. This leads
to a false accounting of available fence registers, causing frequent
mass evictions. Worse, if coupled with the change to make
i915_gem_object_get_fence() report EDEADLK upon fence starvation, the
batchbuffer can fail with only one fence required...
In order to trigger the false accounting, one can simply submit two
batches containing the same 18 [2*(num_avail_fences+1)] buffers. In the
first batch, the first 9 buffers require a fence. In the second batch,
the latter half require a fence. Due to prior pinning of all buffers,
which also then pins the fence register, this results in the false
starvation and forced eviction of the currently active buffers.
Admittedly, such batch buffers require pipelined fencing...
Note, this fixes a severe performance regression with heavy fenced BLT
users such as the Cairo traces firefox-planet-gnome and midori-zoomed on
gen3.
Signed-off-by: Chris Wilson<chris at chris-wilson.co.uk>
Cc: Daniel Vetter<daniel.vetter at ffwll.ch>
Reviewed-by: Daniel Vetter<daniel.vetter at ffwll.ch>
---
drivers/gpu/drm/i915/i915_drv.h | 21 ++++
drivers/gpu/drm/i915/i915_gem.c | 7 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 161 +++++++++++++++++++---------
drivers/gpu/drm/i915/intel_display.c | 21 +++-
4 files changed, 155 insertions(+), 55 deletions(-)
Bringing back this June's thread to live, I noticed that this patch
never made it to the kernel.. is anything still pending on it by a
chance, or it was just MIA?
--
Eugeni Dodonov
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
