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

Abdiel Janulgue abdiel.janulgue at linux.intel.com
Thu Apr 24 13:22:36 CEST 2014


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.

Yep, the previous work-around did include a state cache invalidate.

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

Seems to be a good idea. I'll try to reproduce the problem with igt


> 
> > [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



More information about the Intel-gfx mailing list