On 07/14/2017 08:08 AM, Chris Wilson wrote:
Quoting Oscar Mateo (2017-07-14 15:52:59)
On 07/13/2017 03:28 PM, Rodrigo Vivi wrote:
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...
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?
That is my initial response as well. The kernel does load one context,
just so that the hardware always has space to write to on power saving.
The only batch executed for it is the golden render state. Easy enough
to only initialise that kernel context to isolate whether it is
self-inflicted or that userspace overlooked something in its state
management. (I have the view that even if userspace doesn't think it
needs to use a particular bit of state today, tomorrow it will so will
need it anyway!)
-Chris
Rodrigo, you have access to a CNL: can you make this test? The idea is
to find out if the root cause for the failures you were seeing is the
kernel default context or in the UMD-created contexts.
Thanks,
Oscar
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
