On Wed, Oct 22, 2014 at 09:09:43AM +1000, Dave Airlie wrote: > On 21 October 2014 23:38, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > > Hi Dave, > > > > drm-intel-next-2014-10-03: > > - first batch of skl stage 1 enabling > > - fixes from Rodrigo to the PSR, fbc and sink crc code > > - kerneldoc for the frontbuffer tracking code, runtime pm code and the basic > > interrupt enable/disable functions > > - smaller stuff all over > > drm-intel-next-2014-09-19: > > - bunch more i830M fixes from Ville > > - full ppgtt now again enabled by default > > - more ppgtt fixes from Michel Thierry and Chris Wilson > > - plane config work from Gustavo Padovan > > - spinlock clarifications > > - piles of smaller improvements all over, as usual > > Chris made some noises about PPGTT being broken somewhere on irc last week, > > Chris, did you figure that out? Nope. All full-ppgtt platforms (ivb/byt/hsw) suffer from spontaneously loosing track of the right page directories and end up executing garbage. It correlates with load, so frequently makes igt (and a few tests in particular) die, along with piglit, webgl conformance, benchmarking and even eventually light loads on composited desktops. I've made the pd uncached, added copious flushing, forced switch_mm every time, added noops, cacheline alignment, srm, forced the execution of batches to be synchronous, and yet IPEHR != *ACTHD. The register and command state looks valid. The gpu resets ok and runs fine until the error strikes again. [So I need to test whether switch_mm(aliasing_ppgtt) on every batch fails as well, and whether i915.enable_rc6=0 masks it. There is the worrying bits in bspec that talk of non-RCS as being part of the render context state, but only the RCS pd registers are shown in the context diagrams. I guess I should inspect the context state and see if I can spot the other registers. If context restore (and with rc6 that could happen at any time) switched the pd on the other rings, that would be a nice snafu.] I would suggest that full-ppgtt be disabled unless someone else has had better luck finding a hsd or figuring out the missing magic. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
