[Intel-gfx] [RFC] xf86-video-intel: enable hw-generated binding tables
Abdiel Janulgue
abdiel.janulgue at linux.intel.com
Wed Apr 23 13:21:19 CEST 2014
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 :(
More information about the Intel-gfx
mailing list