intel: Account for potential pinned buffers hogging fences

As the kernel reports the total number of fences, we must guess how many
fences are likely to be pinned. In the typical system these will be only
used by the scanout buffers, of which there may be one per pipe, and any
number of manually pinned fenced buffers. So take a conservative guess
and reserve two fences for use by the system.

Note this reduces the number of fences to 3 for i915 and prior.

Reference:
  http://bugs.freedesktop.org/show_bug.cgi?id=25911
  The latest intel driver 2.10.0 causes kernel oops and system hangs

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
main
Chris Wilson 2010-02-09 08:32:54 +00:00
parent e4a519635f
commit fdcde592c2
1 changed files with 13 additions and 0 deletions

View File

@ -1769,6 +1769,19 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
fprintf(stderr, "param: %d, val: %d\n", gp.param,
*gp.value);
bufmgr_gem->available_fences = 0;
} else {
/* XXX The kernel reports the total number of fences,
* including any that may be pinned.
*
* We presume that there will be at least one pinned
* fence for the scanout buffer, but there may be more
* than one scanout and the user may be manually
* pinning buffers. Let's move to execbuffer2 and
* thereby forget the insanity of using fences...
*/
bufmgr_gem->available_fences -= 2;
if (bufmgr_gem->available_fences < 0)
bufmgr_gem->available_fences = 0;
}
}