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

[Christian König]

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 at 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.

>
> /Thomas
>
>