On Wed, May 3, 2017 at 9:31 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > 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. I'd like to drop as well, and I was hearing people around telling we didn't need anymore, however without this during power on I had bad failures... >> >> -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. so... based on what I saw we need this, I agree the justification is not good because I could never actually understand or make any sense out of this golden context.... But we need a solution to this impasse, to be able to move forward... > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
