| Message ID | 20210723172142.3273510-1-jason@jlekstrand.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/i915: Migrate memory to SMEM when imported cross-device (v8) | expand |
On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand <jason@jlekstrand.net> wrote: > > This patch series fixes an issue with discrete graphics on Intel where we > allowed dma-buf import while leaving the object in local memory. This > breaks down pretty badly if the import happened on a different physical > device. > > v7: > - Drop "drm/i915/gem/ttm: Place new BOs in the requested region" > - Add a new "drm/i915/gem: Call i915_gem_flush_free_objects() in i915_gem_dumb_create()" > - Misc. review feedback from Matthew Auld > v8: > - Misc. review feedback from Matthew Auld > v9: > - Replace the i915/ttm patch with two that are hopefully more correct > > Jason Ekstrand (6): > drm/i915/gem: Check object_can_migrate from object_migrate > drm/i915/gem: Refactor placement setup for i915_gem_object_create* > (v2) > drm/i915/gem: Call i915_gem_flush_free_objects() in > i915_gem_dumb_create() > drm/i915/gem: Unify user object creation (v3) > drm/i915/gem/ttm: Only call __i915_gem_object_set_pages if needed > drm/i915/gem: Always call obj->ops->migrate unless can_migrate fails > > Thomas Hellström (2): > drm/i915/gem: Correct the locking and pin pattern for dma-buf (v8) > drm/i915/gem: Migrate to system at dma-buf attach time (v7) Should I push the series? > > drivers/gpu/drm/i915/gem/i915_gem_create.c | 177 ++++++++-------- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 58 ++++-- > drivers/gpu/drm/i915/gem/i915_gem_object.c | 20 +- > drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 + > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 13 +- > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 190 +++++++++++++++++- > .../drm/i915/gem/selftests/i915_gem_migrate.c | 15 -- > 7 files changed, 341 insertions(+), 136 deletions(-) > > -- > 2.31.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld <matthew.william.auld@gmail.com> wrote: > > On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand <jason@jlekstrand.net> wrote: > > > > This patch series fixes an issue with discrete graphics on Intel where we > > allowed dma-buf import while leaving the object in local memory. This > > breaks down pretty badly if the import happened on a different physical > > device. > > > > v7: > > - Drop "drm/i915/gem/ttm: Place new BOs in the requested region" > > - Add a new "drm/i915/gem: Call i915_gem_flush_free_objects() in i915_gem_dumb_create()" > > - Misc. review feedback from Matthew Auld > > v8: > > - Misc. review feedback from Matthew Auld > > v9: > > - Replace the i915/ttm patch with two that are hopefully more correct > > > > Jason Ekstrand (6): > > drm/i915/gem: Check object_can_migrate from object_migrate > > drm/i915/gem: Refactor placement setup for i915_gem_object_create* > > (v2) > > drm/i915/gem: Call i915_gem_flush_free_objects() in > > i915_gem_dumb_create() > > drm/i915/gem: Unify user object creation (v3) > > drm/i915/gem/ttm: Only call __i915_gem_object_set_pages if needed > > drm/i915/gem: Always call obj->ops->migrate unless can_migrate fails > > > > Thomas Hellström (2): > > drm/i915/gem: Correct the locking and pin pattern for dma-buf (v8) > > drm/i915/gem: Migrate to system at dma-buf attach time (v7) > > Should I push the series? Yes, please. Do we have a solid testing plan for things like this that touch discrete? I tested with mesa+glxgears on my DG1 but haven't run anything more stressful. --Jason > > > > drivers/gpu/drm/i915/gem/i915_gem_create.c | 177 ++++++++-------- > > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 58 ++++-- > > drivers/gpu/drm/i915/gem/i915_gem_object.c | 20 +- > > drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 + > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 13 +- > > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 190 +++++++++++++++++- > > .../drm/i915/gem/selftests/i915_gem_migrate.c | 15 -- > > 7 files changed, 341 insertions(+), 136 deletions(-) > > > > -- > > 2.31.1 > > > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, 26 Jul 2021 at 16:11, Jason Ekstrand <jason@jlekstrand.net> wrote: > > On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld > <matthew.william.auld@gmail.com> wrote: > > > > On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand <jason@jlekstrand.net> wrote: > > > > > > This patch series fixes an issue with discrete graphics on Intel where we > > > allowed dma-buf import while leaving the object in local memory. This > > > breaks down pretty badly if the import happened on a different physical > > > device. > > > > > > v7: > > > - Drop "drm/i915/gem/ttm: Place new BOs in the requested region" > > > - Add a new "drm/i915/gem: Call i915_gem_flush_free_objects() in i915_gem_dumb_create()" > > > - Misc. review feedback from Matthew Auld > > > v8: > > > - Misc. review feedback from Matthew Auld > > > v9: > > > - Replace the i915/ttm patch with two that are hopefully more correct > > > > > > Jason Ekstrand (6): > > > drm/i915/gem: Check object_can_migrate from object_migrate > > > drm/i915/gem: Refactor placement setup for i915_gem_object_create* > > > (v2) > > > drm/i915/gem: Call i915_gem_flush_free_objects() in > > > i915_gem_dumb_create() > > > drm/i915/gem: Unify user object creation (v3) > > > drm/i915/gem/ttm: Only call __i915_gem_object_set_pages if needed > > > drm/i915/gem: Always call obj->ops->migrate unless can_migrate fails > > > > > > Thomas Hellström (2): > > > drm/i915/gem: Correct the locking and pin pattern for dma-buf (v8) > > > drm/i915/gem: Migrate to system at dma-buf attach time (v7) > > > > Should I push the series? > > Yes, please. Do we have a solid testing plan for things like this > that touch discrete? I tested with mesa+glxgears on my DG1 but > haven't run anything more stressful. I think all we really have are the migration related selftests, and CI is not even running them on DG1 due to other breakage. Assuming you ran these locally, I think we just merge the series? > > --Jason > > > > > > > > drivers/gpu/drm/i915/gem/i915_gem_create.c | 177 ++++++++-------- > > > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 58 ++++-- > > > drivers/gpu/drm/i915/gem/i915_gem_object.c | 20 +- > > > drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 + > > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 13 +- > > > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 190 +++++++++++++++++- > > > .../drm/i915/gem/selftests/i915_gem_migrate.c | 15 -- > > > 7 files changed, 341 insertions(+), 136 deletions(-) > > > > > > -- > > > 2.31.1 > > > > > > _______________________________________________ > > > Intel-gfx mailing list > > > Intel-gfx@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, Jul 26, 2021 at 10:29 AM Matthew Auld <matthew.william.auld@gmail.com> wrote: > > On Mon, 26 Jul 2021 at 16:11, Jason Ekstrand <jason@jlekstrand.net> wrote: > > > > On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld > > <matthew.william.auld@gmail.com> wrote: > > > > > > On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand <jason@jlekstrand.net> wrote: > > > > > > > > This patch series fixes an issue with discrete graphics on Intel where we > > > > allowed dma-buf import while leaving the object in local memory. This > > > > breaks down pretty badly if the import happened on a different physical > > > > device. > > > > > > > > v7: > > > > - Drop "drm/i915/gem/ttm: Place new BOs in the requested region" > > > > - Add a new "drm/i915/gem: Call i915_gem_flush_free_objects() in i915_gem_dumb_create()" > > > > - Misc. review feedback from Matthew Auld > > > > v8: > > > > - Misc. review feedback from Matthew Auld > > > > v9: > > > > - Replace the i915/ttm patch with two that are hopefully more correct > > > > > > > > Jason Ekstrand (6): > > > > drm/i915/gem: Check object_can_migrate from object_migrate > > > > drm/i915/gem: Refactor placement setup for i915_gem_object_create* > > > > (v2) > > > > drm/i915/gem: Call i915_gem_flush_free_objects() in > > > > i915_gem_dumb_create() > > > > drm/i915/gem: Unify user object creation (v3) > > > > drm/i915/gem/ttm: Only call __i915_gem_object_set_pages if needed > > > > drm/i915/gem: Always call obj->ops->migrate unless can_migrate fails > > > > > > > > Thomas Hellström (2): > > > > drm/i915/gem: Correct the locking and pin pattern for dma-buf (v8) > > > > drm/i915/gem: Migrate to system at dma-buf attach time (v7) > > > > > > Should I push the series? > > > > Yes, please. Do we have a solid testing plan for things like this > > that touch discrete? I tested with mesa+glxgears on my DG1 but > > haven't run anything more stressful. > > I think all we really have are the migration related selftests, and CI > is not even running them on DG1 due to other breakage. Assuming you > ran these locally, I think we just merge the series? Works for me. Yes, I ran them on my TGL+DG1 box. I've also tested both GL and Vulkan PRIME support with the client running on DG1 and the compositor running on TGL with this series and everything works smooth. --Jason > > > > --Jason > > > > > > > > > > > > drivers/gpu/drm/i915/gem/i915_gem_create.c | 177 ++++++++-------- > > > > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 58 ++++-- > > > > drivers/gpu/drm/i915/gem/i915_gem_object.c | 20 +- > > > > drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 + > > > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 13 +- > > > > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 190 +++++++++++++++++- > > > > .../drm/i915/gem/selftests/i915_gem_migrate.c | 15 -- > > > > 7 files changed, 341 insertions(+), 136 deletions(-) > > > > > > > > -- > > > > 2.31.1 > > > > > > > > _______________________________________________ > > > > Intel-gfx mailing list > > > > Intel-gfx@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, 26 Jul 2021 at 16:32, Jason Ekstrand <jason@jlekstrand.net> wrote: > > On Mon, Jul 26, 2021 at 10:29 AM Matthew Auld > <matthew.william.auld@gmail.com> wrote: > > > > On Mon, 26 Jul 2021 at 16:11, Jason Ekstrand <jason@jlekstrand.net> wrote: > > > > > > On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld > > > <matthew.william.auld@gmail.com> wrote: > > > > > > > > On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand <jason@jlekstrand.net> wrote: > > > > > > > > > > This patch series fixes an issue with discrete graphics on Intel where we > > > > > allowed dma-buf import while leaving the object in local memory. This > > > > > breaks down pretty badly if the import happened on a different physical > > > > > device. > > > > > > > > > > v7: > > > > > - Drop "drm/i915/gem/ttm: Place new BOs in the requested region" > > > > > - Add a new "drm/i915/gem: Call i915_gem_flush_free_objects() in i915_gem_dumb_create()" > > > > > - Misc. review feedback from Matthew Auld > > > > > v8: > > > > > - Misc. review feedback from Matthew Auld > > > > > v9: > > > > > - Replace the i915/ttm patch with two that are hopefully more correct > > > > > > > > > > Jason Ekstrand (6): > > > > > drm/i915/gem: Check object_can_migrate from object_migrate > > > > > drm/i915/gem: Refactor placement setup for i915_gem_object_create* > > > > > (v2) > > > > > drm/i915/gem: Call i915_gem_flush_free_objects() in > > > > > i915_gem_dumb_create() > > > > > drm/i915/gem: Unify user object creation (v3) > > > > > drm/i915/gem/ttm: Only call __i915_gem_object_set_pages if needed > > > > > drm/i915/gem: Always call obj->ops->migrate unless can_migrate fails > > > > > > > > > > Thomas Hellström (2): > > > > > drm/i915/gem: Correct the locking and pin pattern for dma-buf (v8) > > > > > drm/i915/gem: Migrate to system at dma-buf attach time (v7) > > > > > > > > Should I push the series? > > > > > > Yes, please. Do we have a solid testing plan for things like this > > > that touch discrete? I tested with mesa+glxgears on my DG1 but > > > haven't run anything more stressful. > > > > I think all we really have are the migration related selftests, and CI > > is not even running them on DG1 due to other breakage. Assuming you > > ran these locally, I think we just merge the series? > > Works for me. Yes, I ran them on my TGL+DG1 box. I've also tested > both GL and Vulkan PRIME support with the client running on DG1 and > the compositor running on TGL with this series and everything works > smooth. And pushed to drm-intel-gt-next. > > --Jason > > > > > > > > --Jason > > > > > > > > > > > > > > > > drivers/gpu/drm/i915/gem/i915_gem_create.c | 177 ++++++++-------- > > > > > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 58 ++++-- > > > > > drivers/gpu/drm/i915/gem/i915_gem_object.c | 20 +- > > > > > drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 + > > > > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 13 +- > > > > > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 190 +++++++++++++++++- > > > > > .../drm/i915/gem/selftests/i915_gem_migrate.c | 15 -- > > > > > 7 files changed, 341 insertions(+), 136 deletions(-) > > > > > > > > > > -- > > > > > 2.31.1 > > > > > > > > > > _______________________________________________ > > > > > Intel-gfx mailing list > > > > > Intel-gfx@lists.freedesktop.org > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
This patch series fixes an issue with discrete graphics on Intel where we allowed dma-buf import while leaving the object in local memory. This breaks down pretty badly if the import happened on a different physical device. v7: - Drop "drm/i915/gem/ttm: Place new BOs in the requested region" - Add a new "drm/i915/gem: Call i915_gem_flush_free_objects() in i915_gem_dumb_create()" - Misc. review feedback from Matthew Auld v8: - Misc. review feedback from Matthew Auld v9: - Replace the i915/ttm patch with two that are hopefully more correct Jason Ekstrand (6): drm/i915/gem: Check object_can_migrate from object_migrate drm/i915/gem: Refactor placement setup for i915_gem_object_create* (v2) drm/i915/gem: Call i915_gem_flush_free_objects() in i915_gem_dumb_create() drm/i915/gem: Unify user object creation (v3) drm/i915/gem/ttm: Only call __i915_gem_object_set_pages if needed drm/i915/gem: Always call obj->ops->migrate unless can_migrate fails Thomas Hellström (2): drm/i915/gem: Correct the locking and pin pattern for dma-buf (v8) drm/i915/gem: Migrate to system at dma-buf attach time (v7) drivers/gpu/drm/i915/gem/i915_gem_create.c | 177 ++++++++-------- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 58 ++++-- drivers/gpu/drm/i915/gem/i915_gem_object.c | 20 +- drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 + drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 13 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 190 +++++++++++++++++- .../drm/i915/gem/selftests/i915_gem_migrate.c | 15 -- 7 files changed, 341 insertions(+), 136 deletions(-)