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

[Christian König]

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.

>
> We can also validate any conflicts in drm-tip easily before they get baked
> in in drm-next.
>
> So I'd just go with
> - drm-misc-next gets those 10 patches from Christian and the memcpy prep
>    stuff from you, gets send to drm-next (that's probably the last feature
>    pull for 5.14 anyway, maybe another one)
> - drm-intel-gt-next gets send to drm-next
> - topic branch with remaining i915 ttm work that's in flight on top of
>    drm-next and we pull that into drm-misc-next and drm-intel-gt-next as
>    needed
>
> Only thing we need for this is a few days of testing to make sure any
> conflicts between -misc-next and -gt-next are fully validated.
>
> Adding Dave for that so he knows too.
>
>> Whether I push the ttm memcpy stuff before your 10 patches or after
>> shouldn't really matter except it might take some time to resolve the 10
>> patches - drm-intel-gt-next conflict in drm-tip.
>>
>> So OK to merge the memcpy stuff to drm-misc-next now or do you want me to
>> hold on?
>>
>> I'll take a look at what's remaining to review in your series. I guess it's
>> in our interest that both these series get merged asap.
> Yeah that part I think makes sense.
> -Daniel
>
>> /Thomas
>>
>>
>>
>>> Christian.
>>>
>>>> -Daniel