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

[Abdiel Janulgue <abdiel.janulgue@linux.intel.com>]

On Tuesday, April 22, 2014 07:20:58 PM Daniel Vetter wrote:
> On Tue, Apr 22, 2014 at 04:23:12PM +0100, Chris Wilson wrote:
> > On Tue, Apr 22, 2014 at 06:16:34PM +0300, Abdiel Janulgue wrote:
> > > This patch series enables resource streamer for xf86-video-intel UXA.
> > > 
> > > Fixes i965 Mesa driver that makes use of resource streamer optimization
> > > to survive a full piglit run without bricking the machine. Previously,
> > > I get random hungs when doing a full piglit round when enabling RS.
> > > After months of head-scratching, I noticed I didn't quite pay attention
> > > 
> > > to this small detail in bspec:
> > >  "The binding table generator feature has a simple all or nothing
> > >  
> > >   model. If HW generated binding tables are enabled, the driver must
> > >   enable
> > >   the pool and use 3D_HW_BINDING_TABLE_POINTER_* commands."
> > > 
> > > I realized that our xf86-video-intel driver is piping out 3D commands
> > > as well that used the older manual-generated binding table format
> > > that caused a conflict when Mesa is using the hw-generated binding table
> > > format.
> > 
> > This has to be per-context right? Otherwise how do you intend to
> > coordinate multiple clients submitting to the kernel using incompatible
> > command sets? Even in the restricted X/DRI sense, how do you intend to
> > negotiate which to use?
> 
> Hm, I've thought that the MI_BB_START should synchronize with the
> asynchronous RS parsing/processing? Is there no way to disable RS again
> for the next batch in a different context?

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".

> 
> If there's no way to solve this with contexts or some manual reset trick
> using LRIs then we're pretty decently screwed up. Worst case we need to
> stop the gpu and reset it to keep backwards compat :(