Re: [Intel-gfx] Merging TTM branches through the Intel tree?

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

 



On Fri, 2021-06-04 at 16:06 +0200, Christian König wrote:
> Am 04.06.21 um 16:03 schrieb Thomas Hellström:
> > On Fri, 2021-06-04 at 15:38 +0200, Christian König wrote:
> > > Am 04.06.21 um 11:12 schrieb Daniel Vetter:
> > > > On Fri, Jun 04, 2021 at 11:01:40AM +0200, Thomas Hellström
> > > > wrote:
> > > > > On 6/4/21 9:51 AM, Christian König wrote:
> > > > > > Am 03.06.21 um 09:36 schrieb Daniel Vetter:
> > > > > > > On Thu, Jun 3, 2021 at 8:50 AM Thomas Hellström
> > > > > > > <thomas.hellstrom@xxxxxxxxxxxxxxx> wrote:
> > > > > > > > On 6/2/21 8:40 PM, Daniel Vetter wrote:
> > > > > > > > > On Wed, Jun 02, 2021 at 11:48:41AM +0200, Christian
> > > > > > > > > König
> > > > > > > > > wrote:
> > > > > > > > > > Am 02.06.21 um 11:16 schrieb Thomas Hellström
> > > > > > > > > > (Intel):
> > > > > > > > > > > On 6/2/21 10:32 AM, Christian König wrote:
> > > > > > > > > > > > Uff I'm just waiting for feedback from Philip
> > > > > > > > > > > > to
> > > > > > > > > > > > merge a large patch
> > > > > > > > > > > > set for TTM through drm-misc-next.
> > > > > > > > > > > > 
> > > > > > > > > > > > I'm pretty sure we will run into merge
> > > > > > > > > > > > conflicts if
> > > > > > > > > > > > you try to push
> > > > > > > > > > > > your changes through the Intel tree.
> > > > > > > > > > > > 
> > > > > > > > > > > > Christian.
> > > > > > > > > > > OK, so what would be the best approach here?,
> > > > > > > > > > > Adding
> > > > > > > > > > > the TTM patches to
> > > > > > > > > > > drm-misc-next when your set has landed?
> > > > > > > > > > I think I will send out out my set to Matthew once
> > > > > > > > > > more
> > > > > > > > > > for review, then
> > > > > > > > > > push the common TTM stuff to drm-misc-next as much
> > > > > > > > > > as
> > > > > > > > > > possible.
> > > > > > > > > > 
> > > > > > > > > > Then you should be able to land your stuff to
> > > > > > > > > > drm-misc-next and rebase on
> > > > > > > > > > the end result.
> > > > > > > > > > 
> > > > > > > > > > Just need to note to David that drm-misc-next
> > > > > > > > > > should be
> > > > > > > > > > merged to drm-next
> > > > > > > > > > before the Intel patches depending on that stuff
> > > > > > > > > > land
> > > > > > > > > > as well.
> > > > > > > > > Other option (because the backmerges tend to be slow)
> > > > > > > > > is
> > > > > > > > > a
> > > > > > > > > topic branch,
> > > > > > > > > and we just eat/resolve the conflicts in both drm-
> > > > > > > > > misc-
> > > > > > > > > next and
> > > > > > > > > drm-intel-gt-next in the merge commit. If it's not
> > > > > > > > > too
> > > > > > > > > bad (I haven't
> > > > > > > > > looked at what exactly we need for the i915 side from
> > > > > > > > > ttm
> > > > > > > > > in detail).
> > > > > > > > > 
> > > > > > > > > But also often figuring out the topic branch
> > > > > > > > > logistics
> > > > > > > > > takes
> > > > > > > > > longer than
> > > > > > > > > just merging to drm-misc-next as the patches get
> > > > > > > > > ready.
> > > > > > > > > -Daniel
> > > > > > > > Daniel: So the thing we need to get into TTM is the
> > > > > > > > iterator-based
> > > > > > > > move_memcpy which is more adaptable than the current
> > > > > > > > one
> > > > > > > > and needed to
> > > > > > > > support non-linear lmem buffers, some bug-fixes and
> > > > > > > > minor
> > > > > > > > changes to be
> > > > > > > > able to keep our short-term-pinning while on the LRU. A
> > > > > > > > necessary evil.
> > > > > > > > 
> > > > > > > > Christian: it looks like you have landed some TTM
> > > > > > > > changes
> > > > > > > > already, in
> > > > > > > > particular the &bo->mem -> bo->resource change which is
> > > > > > > > the
> > > > > > > > main
> > > > > > > > conflict I think.
> > > > > > Yes, I thought that pushing this with Matthew rb should
> > > > > > solve
> > > > > > at least a
> > > > > > bit of the conflict.
> > > > > > 
> > > > > > > > Is the 10 patches self-allocation series the main
> > > > > > > > remaining part?
> > > > > > Yes, exactly. I only need Matthew's, Daniel's or your ok
> > > > > > and
> > > > > > I'm good to
> > > > > > go as well
> > > > > > 
> > > > > > > > That will probably cause some conflicts with already
> > > > > > > > pushed i915 TTM setup code, but otherwise will not
> > > > > > > > conflict
> > > > > > > > with the
> > > > > > > > rest of the TTM code I think, which should make it
> > > > > > > > possible
> > > > > > > > to bring in
> > > > > > > > our TTM changes after conflict resolution with what
> > > > > > > > you've
> > > > > > > > already
> > > > > > > > pushed. The memcpy code is pretty self-contained.
> > > > > > > I think in that case topic branch on top of drm-next
> > > > > > > (once
> > > > > > > the ttm
> > > > > > > bits we conflict with are there) is probably best, and
> > > > > > > then
> > > > > > > pull that
> > > > > > > into drm-misc-next and drm-intel-gt-next. Merge window
> > > > > > > freeze
> > > > > > > is also
> > > > > > > approach, so without topic branch we'd be stuck until
> > > > > > > like -
> > > > > > > rc2 when
> > > > > > > drm-next reopens. I guess Maarten can do the topic branch
> > > > > > > logistics in
> > > > > > > drm-misc.git for this.
> > > > > > That approach sounds good to me as well.
> > > > > > 
> > > > > > The amdgpu branch had some merge conflicts as well, but
> > > > > > nothing
> > > > > > we
> > > > > > couldn't fix.
> > > > > OK, so this is going to be a little tricky, I guess.
> > > > > 
> > > > >   From what I can tell, the memcpy TTM stuff is resolved
> > > > > locally
> > > > > and can be
> > > > > merged to drm-misc-next immediately. It might have a very
> > > > > minor
> > > > > conflict
> > > > > with your 10 patches I think, if any.
> > > > > 
> > > > > Your 10 patches will conflict slightly with current drm-
> > > > > intel-gt-
> > > > > next I
> > > > > think.
> > > > > 
> > > > > Remaining intel patches will conflict only with current drm-
> > > > > misc-
> > > > > next.
> > > > > 
> > > > > So We could have pull order
> > > > > 
> > > > > - drm-misc-next up to bot not including your 10 patches,
> > > > > - drm-intel-gt-next
> > > > > - drm-misc-next from your 10 paches and onwards,
> > > > > - Intel's ttm enablement topic branch.
> > > > If it's just slight conflicts then I wouldn't bother with
> > > > careful
> > > > merge
> > > > order. Because if we do this we can get around to the i915 ttm
> > > > topic
> > > > branch only when we're back to -rc2.
> > > I've just pushed the remaining 10 patches to drm-misc-next and
> > > ran
> > > into
> > > minor merge conflicts in drm-tip.
> > > 
> > > I'm working on this, but I'm not very familiar with drm-tip
> > > handling.
> > > 
> > > Christian.
> > Np, I'll hold off until Monday.
> 
> Ok I've fixed up drm-tip for amdgpu, but there are also merge
> conflicts 
> for i915.
> 
> Can you handle those? Doesn't looks to hard, but I would prefer not
> to 
> touch code I can't test.
> 
> Christian.

Hi, Christian,
Unfortunately I can't (not until monday at least as I'm off for the
weekend). But I did warn you twice about those.

/Thomas


> 
> > 
> > /Thomas
> > 
> > 
> 





[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux