Re: [PATCH 1/2] rendercopy/bdw: Enable hw-generated binding tables

[Daniel Vetter <daniel@ffwll.ch>]

On Fri, May 16, 2014 at 03:45:24PM +0100, Chris Wilson wrote:
> On Fri, May 16, 2014 at 04:27:34PM +0200, Daniel Vetter wrote:
> > On Fri, May 16, 2014 at 12:36:09PM +0100, Chris Wilson wrote:
> > > On Mon, May 12, 2014 at 06:40:43PM +0200, Daniel Vetter wrote:
> > > > I think as soon as we have the golden context stuff from Mika we could
> > > > drop our usage of restore_inhibit. We only need that to avoid the hw
> > > > getting angry if the context state is illegal afaik.
> > > 
> > > Apart from the contexts being over 100x larger than the state required
> > > to switch between clients, and that the current code regressed to always
> > > update the context between every batch.
> > 
> > We still have the from == to early return in do_switch. That doesn't do
> > what it should any more?
> 
> No.
> 
> commit 0009e46cd54324c4af20b0b52b89973b1b914167
> Author: Ben Widawsky <ben@bwidawsk.net>
> Date:   Fri Dec 6 14:11:02 2013 -0800
> 
>     drm/i915: Track which ring a context ran on
>     
>     Previously we dropped the association of a context to a ring. It is
>     however very important to know which ring a context ran on (we could
>     have reused the other member, but I was nitpicky).
>     
>     This is very important when we switch address spaces, which unlike
>     context objects, do change per ring.
>     
>     As an example, if we have:
>     
>             RCS   BCS
>     ctx            A
>     ctx      A
>     ctx      B
>     ctx            B
>     
>     Without tracking the last ring B ran on, we wouldn't know to switch the
>     address space on BCS in the last row.
>     
>     As a result, we no longer need to track which ring a context "belongs"
>     to, as it never really made much sense anyway.
>     
>     Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
>     Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> was just baloney.

Oh, totally forgotten about that fun. I'll add it as a new subtask to the
big full ppgtt jira :(

Thanks digging this out again.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch