From: "Christian König" <christian.koenig@amd.com> To: "Daniel Vetter" <daniel@ffwll.ch>, "Thomas Hellström" <thomas.hellstrom@linux.intel.com>, "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com> Cc: "Thomas Hellström (Intel)" <thomas_os@shipmail.org>, "Intel Graphics Development" <intel-gfx@lists.freedesktop.org>, "DRI Development" <dri-devel@lists.freedesktop.org>, "Matthew Auld" <matthew.auld@intel.com> Subject: Re: [Intel-gfx] Merging TTM branches through the Intel tree? Date: Fri, 4 Jun 2021 09:51:19 +0200 [thread overview] Message-ID: <68e6057c-df17-64ce-3116-cd5e79578795@amd.com> (raw) In-Reply-To: <CAKMK7uE+fB_+UG668O=QMXwQ9_Xb--KhzehT77HLfBoWve-zLg@mail.gmail.com> 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. Christian. > -Daniel
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com> To: "Daniel Vetter" <daniel@ffwll.ch>, "Thomas Hellström" <thomas.hellstrom@linux.intel.com>, "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com> Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>, DRI Development <dri-devel@lists.freedesktop.org>, Matthew Auld <matthew.auld@intel.com> Subject: Re: [Intel-gfx] Merging TTM branches through the Intel tree? Date: Fri, 4 Jun 2021 09:51:19 +0200 [thread overview] Message-ID: <68e6057c-df17-64ce-3116-cd5e79578795@amd.com> (raw) In-Reply-To: <CAKMK7uE+fB_+UG668O=QMXwQ9_Xb--KhzehT77HLfBoWve-zLg@mail.gmail.com> 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. Christian. > -Daniel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-06-04 7:55 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-02 8:26 Merging TTM branches through the Intel tree? Thomas Hellström 2021-06-02 8:26 ` [Intel-gfx] " Thomas Hellström 2021-06-02 8:32 ` Christian König 2021-06-02 8:32 ` [Intel-gfx] " Christian König 2021-06-02 9:16 ` Thomas Hellström (Intel) 2021-06-02 9:16 ` [Intel-gfx] " Thomas Hellström (Intel) 2021-06-02 9:48 ` Christian König 2021-06-02 9:48 ` [Intel-gfx] " Christian König 2021-06-02 18:40 ` Daniel Vetter 2021-06-02 18:40 ` Daniel Vetter 2021-06-03 6:50 ` Thomas Hellström 2021-06-03 6:50 ` Thomas Hellström 2021-06-03 7:36 ` Daniel Vetter 2021-06-03 7:36 ` Daniel Vetter 2021-06-04 7:51 ` Christian König [this message] 2021-06-04 7:51 ` Christian König 2021-06-04 9:01 ` Thomas Hellström 2021-06-04 9:01 ` Thomas Hellström 2021-06-04 9:12 ` Daniel Vetter 2021-06-04 9:12 ` Daniel Vetter 2021-06-04 13:38 ` Christian König 2021-06-04 13:38 ` Christian König 2021-06-04 14:03 ` Thomas Hellström 2021-06-04 14:03 ` Thomas Hellström 2021-06-04 14:06 ` Christian König 2021-06-04 14:06 ` Christian König 2021-06-04 14:11 ` Thomas Hellström 2021-06-04 14:11 ` Thomas Hellström 2021-06-04 14:14 ` Christian König 2021-06-04 14:14 ` Christian König
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=68e6057c-df17-64ce-3116-cd5e79578795@amd.com \ --to=christian.koenig@amd.com \ --cc=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=maarten.lankhorst@linux.intel.com \ --cc=matthew.auld@intel.com \ --cc=thomas.hellstrom@linux.intel.com \ --cc=thomas_os@shipmail.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.