On 05/03/2017 08:52 AM, Mika Kuoppala
wrote:
Oscar Mateo <oscar.mateo@xxxxxxxxx> writes:On 05/02/2017 09:17 AM, Mika Kuoppala wrote:Chris Wilson <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 <mika.kuoppala@xxxxxxxxx> Cc: Ben Widawsky <ben@xxxxxxxxxxxx> Signed-off-by: Oscar Mateo <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. -MikaHi 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.”
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
