Quoting Chris Wilson (2017-07-13 15:17:41) > Quoting Chris Wilson (2017-07-13 11:27:06) > > The engine also provides a mirror of the CSB write pointer in the HWSP, > > but not of our read pointer. To take advantage of this we need to > > remember where we read up to on the last interrupt and continue off from > > there. This poses a problem following a reset, as we don't know where > > the hw will start writing from, and due to the use of power contexts we > > cannot perform that query during the reset itself. So we continue the > > current modus operandi of delaying the first read of the context-status > > read/write pointers until after the first interrupt. With this we should > > now have eliminated all uncached mmio reads in handling the > > context-status interrupt, though we still have the uncached mmio writes > > for submitting new work, and many uncached mmio reads in the global > > interrupt handler itself. Still a step in the right direction towards > > reducing our resubmit latency, although it appears lost in the noise! > > It is also worth noting that Broxton seems to handle per-engine resets > better when using the HWSP than CSB mmio. Too early to say for sure, > needs a few days to be sure the error doesn't occur. Sadly, that didn't last beyond turning KASAN off. Went back to a config where I could reliably hit the zero mmio reads and then switched HWSP reads back on. Instant garbage from engine A whilst resetting engine B. I really did hope those zeroes where limited to the CSB buffer inside the chipset and didn't make it to the HWSP. Obviously, I'll continue to double check. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
