On Tue, Jul 18, 2017 at 8:15 AM, Oscar Mateo <oscar.mateo@xxxxxxxxx> wrote: > > > > 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. I'm sorry for the delay on this one. On the parts I have now I couldn't reproduce the issues I saw during power-on where null context helped. But anyways apparently we need this right?! What about the 4k+ sanity that Chris raised? Anything we should address first? > > Thanks, > Oscar > -- Rodrigo Vivi Blog: http://blog.vivi.eng.br _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
