On Thu, Jun 15, 2017 at 9:32 AM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> Quoting Jason Ekstrand (2017-06-15 16:58:13) > > On Thu, Jun 15, 2017 at 4:15 AM, Chris Wilson <ch...@chris-wilson.co.uk> > wrote: > > > > Quoting Kenneth Graunke (2017-06-14 21:44:45) > > > If Chris is right, and what we're really seeing is that > MI_SET_CONTEXT > > > needs additional flushing, it probably makes sense to fix the > kernel. > > > If it's really fast clear related, then we should do it in Mesa. > > > > If I'm right, it's more of a userspace problem because you have to > > insert a pipeline stall before STATE_BASE_ADDRESS when switching > between > > blorp/normal and back again, in the same batch. That the > MI_SET_CONTEXT > > may be restoring the dirty GPU state from the previous batch just > means > > that > > you have to think of batches as being one long continuous batch. > > -Chris > > > > > > Given that, I doubt your explanation is correct. Right now, we should > be > > correct under the "long continuous batch" assumption and we're hanging. > So I > > think that either MI_SET_CONTEXT doesn't stall hard enough or we're > conflicting > > with another process somehow. > > What I said was too simplistic, as the MI_SET_CONTEXT would be > introducing side-effects (such as the pipeline being active, hmm, unless > it does flush at the end!). What I mean is that if it is > MI_SET_CONTEXT causing the pipeline to be active, you would need to > treat switching operations within the same pipeline equally. That you > would need a pipeline stall after a blorp/hiz not just to ensure the > data is written but to ensure that the STATE_BASE_ADDRESS doesn't trip > up. > Right. It's entirely possible that MI_SET_CONTEXT could trip of STATE_BASE_ADDRESS or that simple dirty caches can. We've seen cache flushing issues around STATE_BASE_ADDRESS in Vulkan where we set it multiple times per batch. > Of course, now I said that it would be a side-effect of MI_SET_CONTEXT > causing the state of the GPU pipelines to be different from expectation, > it becomes the kernel responsibility to add the flush. Argh! > Yeah... I don't think it would be a bad thing for the kernel to do a end-of-pipe sync after MI_SET_CONTEXT (or maybe before?) but us just handling it in userspace is probably reasonable. > I'm open to putting it into the kernel, though I'd rather userspace > handled it. We want to keep the kernel out of the loop as much as > possible. > I think I agree with you there. Which is why Ken and I merged the patches yesterday :-)
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
