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

["Christian König" <ckoenig.leichtzumerken@gmail.com>]

Am 04.06.21 um 16:11 schrieb Thomas Hellström:
> 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@linux.intel.com> 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.

Ok in this case I will just fix them up as best as I can.

Thanks,
Christian.

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