[Intel-gfx] [PATCH] drm/i915: Allow null render state batchbuffers bigger than one page

Rodrigo Vivi rodrigo.vivi at gmail.com
Thu Jul 13 22:28:54 UTC 2017


On Wed, May 3, 2017 at 9:31 AM, Chris Wilson <chris at chris-wilson.co.uk> 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 at intel.com> writes:
>>
>>
>>  On 05/02/2017 09:17 AM, Mika Kuoppala wrote:
>>
>>  Chris Wilson [2]<chris at chris-wilson.co.uk> 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 at intel.com>
>>  Cc: Ben Widawsky [4]<ben at bwidawsk.net>
>>  Signed-off-by: Oscar Mateo [5]<oscar.mateo at intel.com>
>>
>>  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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br


More information about the Intel-gfx mailing list