On Wed, May 03, 2017 at 09:12:18AM +0000, Oscar Mateo wrote: > On 05/03/2017 08:52 AM, Mika Kuoppala wrote: > > Oscar Mateo [1]<oscar.mateo@xxxxxxxxx> writes: > > > On 05/02/2017 09:17 AM, Mika Kuoppala wrote: > > Chris Wilson [2]<chris@xxxxxxxxxxxxxxxxxx> writes: > > > On Fri, Apr 28, 2017 at 09:11:06AM +0000, Oscar Mateo wrote: > > The new batchbuffer for CNL surpasses the 4096 byte mark. > > Cc: Mika Kuoppala [3]<mika.kuoppala@xxxxxxxxx> > Cc: Ben Widawsky [4]<ben@xxxxxxxxxxxx> > Signed-off-by: Oscar Mateo [5]<oscar.mateo@xxxxxxxxx> > > Evil, 4k+ of nothing-ness that userspace then has to configure for itself > for correctness anyway. > > Patch looks ok, but still question the sanity. > > Is there a requirement for CNL to init the renderstate? > > I would like to drop the render state init from CNL if > we can't find evidence that it needs it. Bspec indicates > that it doesnt. > > -Mika > > Hi Mika, > > I can double-check with the hardware architects, but word around here is > that render state init has never stopped being a requirement. Where did > you see in the BSpec that it is not required for CNL? > > > It would be great if you could refresh the answer and perhaps > even get some answers to the 'why' parts. > > In the "Context Descriptor Format" section, it says: > "Render CS Only: Render state need not be initialized; the Render > Context Restore Inhibit bit in the Context/Save image in memory should > be set to prevent restoring garbage render context." > > -Mika > > :_( > > The same section also says: > > Â > > â**See the Logical Ring Context Format section for details.â** > > Â > > And then â**Logical Ring Context Formatâ** section goes on to say: > > Â > > â**It is tedious for software to populate the engine context as per the > requirements, it is recommended to implicitly use engine to populate this > portion of the context. [â*¦] Software must program all the state required > to initialize the engine in the ring buffer which would initialize the > hardware state.â** Yet what the kernel programs is completely garbage for the user, so the user still has to program the initial GPU state to their own specifications. Just say no to policy in the kernel. We need a stronger reason than this, and if that was the only reason the original render state was merged, I am very angry. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
