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? 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 :( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
