Re: [PULL] drm-intel-next

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 22 October 2014 17:05, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> 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

Thanks Chris for the report,

Daniel, fill in the swear words where you like, but yeah don't think I
want to pull this in this state.

Either pull the enable ppgtt patch or revert it on top,

Thanks,
Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux