From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PULL] drm-intel-next Date: Wed, 22 Oct 2014 08:05:26 +0100 Message-ID: <20141022070526.GE13512@nuc-i3427.alporthouse.com> References: <20141021125505.GA7420@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Dave Airlie Cc: Daniel Vetter , "intel-gfx@lists.freedesktop.org" , dri-devel List-Id: dri-devel@lists.freedesktop.org On Wed, Oct 22, 2014 at 09:09:43AM +1000, Dave Airlie wrote: > On 21 October 2014 23:38, Daniel Vetter 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