[Intel-gfx] [RFC] xf86-video-intel: enable hw-generated binding tables

[Abdiel Janulgue]

On Wednesday, April 23, 2014 08:50:21 PM Ville Syrjälä wrote:
> On Wed, Apr 23, 2014 at 06:52:09PM +0200, Daniel Vetter wrote:
> > On Wed, Apr 23, 2014 at 1:21 PM, Abdiel Janulgue
> > 
> > <abdiel.janulgue at linux.intel.com> wrote:
> > > I've already tried disabling RS at the end of every batch so that next
> > > batch in different context can continue to use older non-RS format.
> > > That does not work either and still causes hangs.
> > > 
> > > What I've seen so far, it seems GPU does not like switching the format
> > > of
> > > commands from RS-format to non-RS format. It's either one way or the
> > > other. If switched on, it affects subsequent contexes henceforth
> > > expecting RS-format commands until the GPU gets reset. That's probably
> > > the note in bspec:
> > > 
> > > "the binding table generator feature has a simple all or nothing model".
> > 
> > Oh hooray, that's just awesome :( So we indeed need to stop the gpu
> > and reset it if there's a non-RS render batch after any RS render
> > batch.
> 
> I'm not sure I buy it. There's an example in the spec showing how to
> disable the RS around eg. GPGPU workloads and re-enable it for 3D
> workloads even within one batch. I guess it's possible that the GPGPU
> pipeline mode is somehow special here, but since the RS state is
> supposed to be saved to the context I'm thinking you should be able to
> disable it whenever you want.
> 
> What's really confusing with that example is the fact that it first
> re-enables the binding tables and then the RS, but then there's a note
> after that saying you have to those steps in the opposite order.
> 
> Anyhoo, I'm wondering if the problems are simply due to disabling RS but
> leaving the binding tables enabled?

Yes, the work-around I tried previously is that at the end of each batch both 
hw-binding tables and RS are disabled in that particular order.

> 
> So one idea might be that when we switch from executing an RS batch to a
> non-RS batch, we should disable the RS and binding tables manually. We
> would then have to demand that any user batch which needs the binding
> tables enabled must enable them, even if if we just executed a batch that
> already used the binding tables. And when we need to disable the RS and
> binding tables we could either have the kernel do that autmagically when
> it notices a RS->non-RS transition, or we could also demand that all user
> batches must disable the binding tables at the end. But maybe demanding
> that from every batch would incur some extra overhead? In any case it
> should be fairly easy to try that and see if it cures the hangs. Or are
> you already doing things that way?

This is actually what current RS implementation in Mesa does. It explicitly 
enables RS then hw-binding tables for each batch start and then the tear-down 
work-around at the batch end I mentioned  above; which didn't help at all.

Anyway I haven't tried the work-around where we explictly only disable the BT 
and RS on the other user-space clients (xorg driver in this case) when Mesa is 
using RS instead of forcing the reset of the clients to use RS format.  I'll 
try that first and let you know if it works. If it does, it might be more 
efficient to do that in the kernel?

--Abdiel