[Intel-gfx] [PULL] drm-intel-next

[Chris Wilson]

On Tue, Dec 22, 2015 at 04:31:22PM +0000, Tvrtko Ursulin wrote:
> 
> On 22/12/15 14:31, Chris Wilson wrote:
> >On Tue, Dec 22, 2015 at 03:05:14PM +0100, Daniel Vetter wrote:
> >>On Tue, Dec 22, 2015 at 11:37:18AM +0100, Daniel Vetter wrote:
> >>>Hi Dave,
> >>>
> >>>Final 4.5 feature pull for drm/i915!
> >>>
> >>>drm-intel-next-2015-12-18:
> >>>- fix atomic watermark recomputation logic (Maarten)
> >>>- modeset sequence fixes for LPT (Ville)
> >>>- more kbl enabling&prep work (Rodrigo, Wayne)
> >>>- first bits for mst audio
> >>>- page dirty tracking fixes from Dave Gordon
> >>>- new get_eld hook from Takashi, also included in the sound tree
> >>>- fixup cursor handling when placed at address 0 (Ville)
> >>>- refactor VBT parsing code (Jani)
> >>>- rpm wakelock debug infrastructure ( Imre)
> >>>- fbdev is pinned again (Chris)
> >>>- tune the busywait logic to avoid wasting cpu cycles (Chris)
> >>>
> >>>Two small caveats as a heads up:
> >>>- the runtime pm wakelock debug stuff catches a few bugs. rpm is disabled
> >>>   by default, but lots enable it (e.g. powertop does), and we iirc have
> >>>   fixes floating for most. If we can't squeeze them all in for 4.5 because
> >>>   too big or late we can just tune down the dmesg noise since the
> >>>   uncovered bugs are all as old as rpm support.
> >>>- softpin is still thrashing around: Chris complains that the ABI can't be
> >>>   used of anything else than beignet, but I think that's ok since easy to
> >>>   remedy and softpin was done primarily for buffered svm opencl mode. And
> >>>   then there's some confusion around canonical 48bit addresses that I
> >>>   don't fully understand myself. I expect Tvrtko to handle this before
> >>>   your merge window pull goes out.
> >>
> >>So just with Tvrtko and the canonical address is something
> >>userspace/beignet will never hit under legitimate usage. So it's just a
> >>bit of closing a corner-case, and the patch+testcase is ready except for
> >>bit of final polish and unfortunately people going on holidays already.
> >
> >Nope, it was reported in the wild and it imposes an ABI constraint on
> >the execobject.offsets.
> 
> Plan is for "drm/i915: Avoid writing relocs with addresses in
> non-canonical form" to be ready as a fixup either before, or
> slightly after rc1. As long as we hit that, slight wobbling in the
> ABI between two release candidates shouldn't be an issue. That is my
> understanding at least.

What about the other ABI issue you just ignored? What about the severe
scaling issues that were known and addressed before you pushed a patch
*out of context*?

> Especially given how the announced user plans to pass in user
> pointer allocated addresses which will already be in canonical
> format.

Not good enough for ABI as the existing code that you just enabled
didn't adhere to the required ABI.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre