[Intel-gfx] [PATCH] drmmode: unreserve userspace fences

Daniel Vetter daniel at ffwll.ch
Sun Jan 31 23:20:18 CET 2010


On Sun, Jan 31, 2010 at 11:26:24AM -0800, Eric Anholt wrote:
> On Sun, 31 Jan 2010 11:59:56 +0100, Daniel Vetter <daniel at ffwll.ch> wrote:
> > Hi Eric,
> > 
> > I've justed noticed that you pushed a patch to fix the kernel. But just
> > patching the kernel is not enough because new userspaces is still broken
> > for older kernels. And currently "older kernels" means _any_ released
> > mainline kernel.
> > 
> > Without this patch I'm experiencing unnecessary uxa fallbacks (due to
> > failed execbuf ioctls due to fence starvation).
> > 
> > Please reconsider applying.
> 
> Unless required, we try to avoid adding workarounds in one part of our
> driver for bugs in other parts of our driver.  Given that the kernel
> backport patch is smaller than the workaround patch, I think the
> solution is obvious: test and send the kernel fix to stable at kernel.org.
> 
> If you've got failed execbuf due to fence starvation, then something
> else is wrong, because that should never happen unless there just aren't
> enough fences for the number of tiled buffers in one single operation.
> Looks like libdrm is using the NUM_FENCES_AVAIL as how many fences it
> can use, but there are pinned scanout buffers holding onto fences so the
> number of available fences for an execbuf is actually less than that.
> Maybe NUM_FENCES_AVAIL should report (num_fences - start_fence_reg -
> num_active_scanout_fences) or (num_fences - start_fence_reg -
> possible_active_scanout_fences).

Ok. I'll look into this. The whole fence accounting in libdrm_intel seems
pretty ad-hoc by a quick look, anyway. Perhaps add a small section to the
relnotes that on i8xx you need at least kernel 2.6.33 to fix this problem.

And related to pinned buffers: Are there any plans on deprecating kernel
drm apis like the pin/unpin stuff, which is positively evil for
kms/execbuf? I think i915 xvmc still abuses this ... Nuking this would
make the fence accounting a tad bit more reliable.

-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48



More information about the Intel-gfx mailing list