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 :( _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
