[Intel-gfx] [PATCH 1/2] drm/i915: Disallow pin ioctl completely for kms drivers

[Chris Wilson]

On Mon, Nov 24, 2014 at 03:10:05PM +0100, Daniel Vetter wrote:
> On Mon, Nov 24, 2014 at 10:35:29AM +0000, Chris Wilson wrote:
> > On Mon, Nov 24, 2014 at 11:30:24AM +0100, Daniel Vetter wrote:
> > > The problem here is that SNA pins batchbuffers to etch out a bit more
> > > performance. Iirc it started out as a w/a for i830M (which we've
> > > implemented in the kernel since a long time already).
> > 
> > Hmm, we only finally fixed it in the kernel a couple of months ago.
> 
> The original wa hack has landed in 3.8:
> 
> commit b45305fce5bb1abec263fcff9d81ebecd6306ede
> Author: Daniel Vetter <daniel.vetter at ffwll.ch>
> Date:   Mon Dec 17 16:21:27 2012 +0100
> 
>     drm/i915: Implement workaround for broken CS tlb on i830/845
> 
> The follow-up fix from you was cc: stable:
> 
> commit c4d69da167fa967749aeb70bc0e94a457e5d00c1
> Author: Chris Wilson <chris at chris-wilson.co.uk>
> Date:   Mon Sep 8 14:25:41 2014 +0100
> 
>     drm/i915: Evict CS TLBs between batches
> 
> So as long as people backport all of this and don't try to run it on 3.8
> we should be fine I think wrt backwards/forwards compat. I'll add this to
> the commit message.

You should also mention that the kernel w/a is inferior to the userspace
w/a to tune of 10-20%.
 
> > > The problem is
> > > that the pin ioctl wasn't added in
> > > 
> > > commit d23db88c3ab233daed18709e3a24d6c95344117f
> > > Author: Chris Wilson <chris at chris-wilson.co.uk>
> > > Date:   Fri May 23 08:48:08 2014 +0200
> > > 
> > >     drm/i915: Prevent negative relocation deltas from wrapping
> > > 
> > > Fix this by simply disallowing pinning from userspace so that the
> > > kernel is in full control of batch placement again. Especially since
> > > distros are moving towards running X as non-root, so most users won't
> > > even be able to see any benefits.
> > 
> > Pinning is a useful tool and it would also be useful to have again on
> > gen6+.
> 
> I think softpin or similar is doable with ppgtt. But with shared ggtt I'm
> not really enthusiastic about providing this kind of rope to userspace.
> And softpin is a different type of pinning, so we don't really lose
> anything by ripping out the userspace hard pinning ioctls.

I am not talking about softpin, but being able to pin memory and a GGTT
binding itself is useful.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre