[Intel-gfx] [PULL] drm-intel-next
chris at chris-wilson.co.uk
Wed Dec 23 02:09:26 PST 2015
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!
> >>>- 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
Not good enough for ABI as the existing code that you just enabled
didn't adhere to the required ABI.
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx