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

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

Hi all!

On Thursday, April 24, 2014 01:17:14 PM Ville Syrjälä wrote:
> On Thu, Apr 24, 2014 at 11:25:15AM +0300, Abdiel Janulgue wrote:
> > On Thursday, April 24, 2014 07:06:34 AM Chris Wilson wrote:
> > > On Thu, Apr 24, 2014 at 09:08:14AM +0300, Abdiel Janulgue wrote:
> > > > 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.
> > 
> > I hate to break the bad news. Tried this just now - still get hangs :(
> > 
> > So I guess, all userspace clients* does need to use RS-format if we use
> > this feature. GPGPU workloads seems to be special use-case where the RS
> > hwbinding table format can be disabled. Otherwise, I guess we are stuck
> > with this inflexibility.
> 
> The spec also says this:
> "When switching between HW and SW binding table generation,
> SW must issue a state cache invalidate."
> 
> So it does look like they were expecting people to switch between the
> two modes.
> 
> Do you have any igt test for RS? Maybe add an option into rendercopy to
> make use of RS? Then we could write some tests that try to hit this
> problem w/o requiring Mesa.

I've modified igt rendercopy to test switching RS format on and off.

Good news and bad news!

Good news is that switching between RS binding tables and SW format
works seamlessly in BDW! Bad news for HSW because the problems I describe 
above only happens on that chip.

This is a HW issue then.

=Abdiel


> 
> > [1]
> > On the other hand, it doesn't seem all that bad though. The RS hw-binding
> > table format are only needed for clients that submit vertex and pixel
> > shader commands. I've identified currently just UXA and SNA that seem to
> > use this besides Mesa. OpenCL is not affected.
> > 
> > > > If it does, it
> > > > might be more efficient to do that in the kernel?
> > > 
> > > It has to be done in the kernel in order for interoperability with third
> > > party clients.
> > > -Chris