On Thu, Aug 24, 2017 at 3:39 PM, Oscar Mateo <oscar.mateo@xxxxxxxxx> wrote: > > > On 08/23/2017 05:01 PM, Rodrigo Vivi wrote: >> >> 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? > > > I don't think Chris had any problem with the batchbuffer being bigger than > 4k per se. His concern was: "why do we need to send this batchbuffer from > the KMD at all if the UMD has to send something very similar anyway?". > Even if this was true (I haven't found anybody to confirm or deny it) there > is still the question of the kernel context (which would never get > initialized to valid values by the UMD). so, chris, rv-b? acked-by? > The test was to only send the > golden state for the kernel context (and nothing else) and see if your > issues went away. > > Since your issues went away on their own without any golden state > whatsoever... does that mean Mesa fixed something they were missing during > the PO? not sure what it was anymore > > -- Rodrigo Vivi Blog: http://blog.vivi.eng.br _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
