On Fri, 2015-09-18 at 10:02 +0100, Chris Wilson wrote: > On Thu, Sep 17, 2015 at 07:17:44PM +0300, Imre Deak wrote: > > The execlist context object is mapped with a CPU/GPU coherent mapping > > everywhere, but on BXT A stepping due to a HW issue the coherency is not > > guaranteed. To work around this flush the context object after pinning > > it (to flush cache lines left by the context initialization/read-back > > from backing storage) and mark it as uncached so later updates during > > context switching will be coherent. > > > > I noticed this problem via a GPU hang, where IPEHR pointed to an invalid > > opcode value. I couldn't find this value on the ring but looking at the > > contents of the active context object it turned out to be a parameter > > dword of a bigger command there. The original command opcode itself > > was zeroed out, based on the above I assume due to a CPU writeback of > > the corresponding cacheline. When restoring the context the GPU would > > jump over the zeroed out opcode and hang when trying to execute the > > above parameter dword. > > > > I could easily reproduce this by running igt/gem_render_copy_redux and > > gem_tiled_blits/basic in parallel, but I guess it could be triggered by > > anything involving frequent switches between two separate contexts. With > > this workaround I couldn't reproduce the problem. > > > > v2: > > - instead of clflushing after updating the tail and PDP values during > > context switching, map the corresponding page as uncached to avoid a > > race between CPU and GPU, both updating the same cacheline at the same > > time (Ville) > > No. Changing PAT involves a stop_machine() and is severely detrimental > to performance (context creation overhead does impact userspace). Hm, where on that path is stop_machine(), I haven't found it. I guess there is an overhead because of the TLB flush on each CPU, I haven't benchmarked it. If that's a real issue (atm this is only a w/a for stepping A) we could have a cache of uncached pages. > Mapping it as uncached doesn't remove the race anyway. Please explain, I do believe it does. --Imre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
