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

[Oscar Mateo <oscar.mateo@intel.com>]

On 07/13/2017 03:28 PM, Rodrigo Vivi wrote:
> On Wed, May 3, 2017 at 9:31 AM, Chris Wilson <chris@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@intel.com> writes:
>>>
>>>
>>>   On 05/02/2017 09:17 AM, Mika Kuoppala wrote:
>>>
>>>   Chris Wilson [2]<chris@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@intel.com>
>>>   Cc: Ben Widawsky [4]<ben@bwidawsk.net>
>>>   Signed-off-by: Oscar Mateo [5]<oscar.mateo@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...
>

The best I could get from architecture (+Raf) is that setting valid and 
coherent values for the whole render state is required as soon as the 
context is created, no matter who does it. If you see failures when the 
KMD does not do it, that means the UMD must be missing something, right?

>>>   -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@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
>


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx