* Merging TTM branches through the Intel tree? @ 2021-06-02 8:26 ` Thomas Hellström 0 siblings, 0 replies; 30+ messages in thread From: Thomas Hellström @ 2021-06-02 8:26 UTC (permalink / raw) To: Christian König, DRI Development, Intel Graphics Development Cc: Matthew Auld Christian, Are you OK with merging the TTM brances from the i915 TTM enablement series through the intel tree? Thanks, Thomas ^ permalink raw reply [flat|nested] 30+ messages in thread
* [Intel-gfx] Merging TTM branches through the Intel tree? @ 2021-06-02 8:26 ` Thomas Hellström 0 siblings, 0 replies; 30+ messages in thread From: Thomas Hellström @ 2021-06-02 8:26 UTC (permalink / raw) To: Christian König, DRI Development, Intel Graphics Development Cc: Matthew Auld Christian, Are you OK with merging the TTM brances from the i915 TTM enablement series through the intel tree? Thanks, Thomas _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Merging TTM branches through the Intel tree? 2021-06-02 8:26 ` [Intel-gfx] " Thomas Hellström @ 2021-06-02 8:32 ` Christian König -1 siblings, 0 replies; 30+ messages in thread From: Christian König @ 2021-06-02 8:32 UTC (permalink / raw) To: Thomas Hellström, DRI Development, Intel Graphics Development Cc: Matthew Auld 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. Am 02.06.21 um 10:26 schrieb Thomas Hellström: > Christian, Are you OK with merging the TTM brances from the i915 TTM > enablement series through the intel tree? > > Thanks, > Thomas > > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? @ 2021-06-02 8:32 ` Christian König 0 siblings, 0 replies; 30+ messages in thread From: Christian König @ 2021-06-02 8:32 UTC (permalink / raw) To: Thomas Hellström, DRI Development, Intel Graphics Development Cc: Matthew Auld 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. Am 02.06.21 um 10:26 schrieb Thomas Hellström: > Christian, Are you OK with merging the TTM brances from the i915 TTM > enablement series through the intel tree? > > Thanks, > Thomas > > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Merging TTM branches through the Intel tree? 2021-06-02 8:32 ` [Intel-gfx] " Christian König @ 2021-06-02 9:16 ` Thomas Hellström (Intel) -1 siblings, 0 replies; 30+ messages in thread From: Thomas Hellström (Intel) @ 2021-06-02 9:16 UTC (permalink / raw) To: Christian König, Thomas Hellström, DRI Development, Intel Graphics Development Cc: Matthew Auld 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? Thanks, Thomas ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? @ 2021-06-02 9:16 ` Thomas Hellström (Intel) 0 siblings, 0 replies; 30+ messages in thread From: Thomas Hellström (Intel) @ 2021-06-02 9:16 UTC (permalink / raw) To: Christian König, Thomas Hellström, DRI Development, Intel Graphics Development Cc: Matthew Auld 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? Thanks, Thomas _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Merging TTM branches through the Intel tree? 2021-06-02 9:16 ` [Intel-gfx] " Thomas Hellström (Intel) @ 2021-06-02 9:48 ` Christian König -1 siblings, 0 replies; 30+ messages in thread From: Christian König @ 2021-06-02 9:48 UTC (permalink / raw) To: Thomas Hellström (Intel), Thomas Hellström, DRI Development, Intel Graphics Development Cc: Matthew Auld 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. Christian. > > Thanks, > > Thomas > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? @ 2021-06-02 9:48 ` Christian König 0 siblings, 0 replies; 30+ messages in thread From: Christian König @ 2021-06-02 9:48 UTC (permalink / raw) To: Thomas Hellström (Intel), Thomas Hellström, DRI Development, Intel Graphics Development Cc: Matthew Auld 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. Christian. > > Thanks, > > Thomas > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? 2021-06-02 9:48 ` [Intel-gfx] " Christian König @ 2021-06-02 18:40 ` Daniel Vetter -1 siblings, 0 replies; 30+ messages in thread From: Daniel Vetter @ 2021-06-02 18:40 UTC (permalink / raw) To: Christian König Cc: Thomas Hellström, Thomas Hellström (Intel), Intel Graphics Development, DRI Development, Matthew Auld 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 Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? @ 2021-06-02 18:40 ` Daniel Vetter 0 siblings, 0 replies; 30+ messages in thread From: Daniel Vetter @ 2021-06-02 18:40 UTC (permalink / raw) To: Christian König Cc: Thomas Hellström, Intel Graphics Development, DRI Development, Matthew Auld 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 Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? 2021-06-02 18:40 ` Daniel Vetter @ 2021-06-03 6:50 ` Thomas Hellström -1 siblings, 0 replies; 30+ messages in thread From: Thomas Hellström @ 2021-06-03 6:50 UTC (permalink / raw) To: Daniel Vetter, Christian König Cc: Thomas Hellström (Intel), Intel Graphics Development, DRI Development, Matthew Auld 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. Is the 10 patches self-allocation series the main remaining part? 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. /Thomas ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? @ 2021-06-03 6:50 ` Thomas Hellström 0 siblings, 0 replies; 30+ messages in thread From: Thomas Hellström @ 2021-06-03 6:50 UTC (permalink / raw) To: Daniel Vetter, Christian König Cc: Intel Graphics Development, DRI Development, Matthew Auld 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. Is the 10 patches self-allocation series the main remaining part? 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. /Thomas _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? 2021-06-03 6:50 ` Thomas Hellström @ 2021-06-03 7:36 ` Daniel Vetter -1 siblings, 0 replies; 30+ messages in thread From: Daniel Vetter @ 2021-06-03 7:36 UTC (permalink / raw) To: Thomas Hellström, Maarten Lankhorst Cc: Thomas Hellström (Intel), Intel Graphics Development, Christian König, DRI Development, Matthew Auld 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. Is the 10 patches self-allocation series the main > remaining part? 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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? @ 2021-06-03 7:36 ` Daniel Vetter 0 siblings, 0 replies; 30+ messages in thread From: Daniel Vetter @ 2021-06-03 7:36 UTC (permalink / raw) To: Thomas Hellström, Maarten Lankhorst Cc: Intel Graphics Development, Christian König, DRI Development, Matthew Auld 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. Is the 10 patches self-allocation series the main > remaining part? 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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? 2021-06-03 7:36 ` Daniel Vetter @ 2021-06-04 7:51 ` Christian König -1 siblings, 0 replies; 30+ messages in thread From: Christian König @ 2021-06-04 7:51 UTC (permalink / raw) To: Daniel Vetter, Thomas Hellström, Maarten Lankhorst Cc: Thomas Hellström (Intel), Intel Graphics Development, DRI Development, Matthew Auld 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? @ 2021-06-04 7:51 ` Christian König 0 siblings, 0 replies; 30+ messages in thread From: Christian König @ 2021-06-04 7:51 UTC (permalink / raw) To: Daniel Vetter, Thomas Hellström, Maarten Lankhorst Cc: Intel Graphics Development, DRI Development, Matthew Auld 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? 2021-06-04 7:51 ` Christian König @ 2021-06-04 9:01 ` Thomas Hellström -1 siblings, 0 replies; 30+ messages in thread From: Thomas Hellström @ 2021-06-04 9:01 UTC (permalink / raw) To: Christian König, Daniel Vetter, Maarten Lankhorst Cc: Thomas Hellström (Intel), Intel Graphics Development, DRI Development, Matthew Auld 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. 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. /Thomas > > Christian. > >> -Daniel > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? @ 2021-06-04 9:01 ` Thomas Hellström 0 siblings, 0 replies; 30+ messages in thread From: Thomas Hellström @ 2021-06-04 9:01 UTC (permalink / raw) To: Christian König, Daniel Vetter, Maarten Lankhorst Cc: Intel Graphics Development, DRI Development, Matthew Auld 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. 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. /Thomas > > Christian. > >> -Daniel > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? 2021-06-04 9:01 ` Thomas Hellström @ 2021-06-04 9:12 ` Daniel Vetter -1 siblings, 0 replies; 30+ messages in thread From: Daniel Vetter @ 2021-06-04 9:12 UTC (permalink / raw) To: Thomas Hellström, Dave Airlie Cc: Thomas Hellström (Intel), DRI Development, Matthew Auld, Intel Graphics Development, Christian König 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. 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 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? @ 2021-06-04 9:12 ` Daniel Vetter 0 siblings, 0 replies; 30+ messages in thread From: Daniel Vetter @ 2021-06-04 9:12 UTC (permalink / raw) To: Thomas Hellström, Dave Airlie Cc: DRI Development, Matthew Auld, Intel Graphics Development, Christian König 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. 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 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? 2021-06-04 9:12 ` Daniel Vetter @ 2021-06-04 13:38 ` Christian König -1 siblings, 0 replies; 30+ messages in thread From: Christian König @ 2021-06-04 13:38 UTC (permalink / raw) To: Daniel Vetter, Thomas Hellström, Dave Airlie Cc: Thomas Hellström (Intel), Intel Graphics Development, DRI Development, Matthew Auld 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. > > 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? @ 2021-06-04 13:38 ` Christian König 0 siblings, 0 replies; 30+ messages in thread From: Christian König @ 2021-06-04 13:38 UTC (permalink / raw) To: Daniel Vetter, Thomas Hellström, Dave Airlie Cc: Intel Graphics Development, DRI Development, Matthew Auld 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. > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? 2021-06-04 13:38 ` Christian König @ 2021-06-04 14:03 ` Thomas Hellström -1 siblings, 0 replies; 30+ messages in thread From: Thomas Hellström @ 2021-06-04 14:03 UTC (permalink / raw) To: Christian König, Daniel Vetter, Dave Airlie Cc: Thomas Hellström (Intel), Intel Graphics Development, DRI Development, Matthew Auld 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. /Thomas ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? @ 2021-06-04 14:03 ` Thomas Hellström 0 siblings, 0 replies; 30+ messages in thread From: Thomas Hellström @ 2021-06-04 14:03 UTC (permalink / raw) To: Christian König, Daniel Vetter, Dave Airlie Cc: Intel Graphics Development, DRI Development, Matthew Auld 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. /Thomas _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? 2021-06-04 14:03 ` Thomas Hellström @ 2021-06-04 14:06 ` Christian König -1 siblings, 0 replies; 30+ messages in thread From: Christian König @ 2021-06-04 14:06 UTC (permalink / raw) To: Thomas Hellström, Daniel Vetter, Dave Airlie Cc: Thomas Hellström (Intel), Intel Graphics Development, DRI Development, Matthew Auld 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. > > /Thomas > > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? @ 2021-06-04 14:06 ` Christian König 0 siblings, 0 replies; 30+ messages in thread From: Christian König @ 2021-06-04 14:06 UTC (permalink / raw) To: Thomas Hellström, Daniel Vetter, Dave Airlie Cc: Intel Graphics Development, DRI Development, Matthew Auld 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. > > /Thomas > > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? 2021-06-04 14:06 ` Christian König @ 2021-06-04 14:11 ` Thomas Hellström -1 siblings, 0 replies; 30+ messages in thread From: Thomas Hellström @ 2021-06-04 14:11 UTC (permalink / raw) To: Christian König, Daniel Vetter, Dave Airlie Cc: Thomas Hellström (Intel), Intel Graphics Development, DRI Development, Matthew Auld 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. /Thomas > > > > > /Thomas > > > > > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? @ 2021-06-04 14:11 ` Thomas Hellström 0 siblings, 0 replies; 30+ messages in thread From: Thomas Hellström @ 2021-06-04 14:11 UTC (permalink / raw) To: Christian König, Daniel Vetter, Dave Airlie Cc: Intel Graphics Development, DRI Development, Matthew Auld 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. /Thomas > > > > > /Thomas > > > > > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? 2021-06-04 14:11 ` Thomas Hellström @ 2021-06-04 14:14 ` Christian König -1 siblings, 0 replies; 30+ messages in thread From: Christian König @ 2021-06-04 14:14 UTC (permalink / raw) To: Thomas Hellström, Daniel Vetter, Dave Airlie Cc: Thomas Hellström (Intel), Intel Graphics Development, DRI Development, Matthew Auld 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 >>> >>> > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [Intel-gfx] Merging TTM branches through the Intel tree? @ 2021-06-04 14:14 ` Christian König 0 siblings, 0 replies; 30+ messages in thread From: Christian König @ 2021-06-04 14:14 UTC (permalink / raw) To: Thomas Hellström, Daniel Vetter, Dave Airlie Cc: Intel Graphics Development, DRI Development, Matthew Auld 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 >>> >>> > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2021-06-04 14:42 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.