From 504245a5ab6b6e1bfe0280baa4885c551e082099 Mon Sep 17 00:00:00 2001 From: Daniel Stone Date: Thu, 3 Aug 2023 16:47:29 +0100 Subject: doc: uapi: Add document describing dma-buf semantics Since there's a lot of confusion around this, document both the rules and the best practices around negotiating, allocating, importing, and using buffers when crossing context/process/device/subsystem boundaries. This ties up all of dma-buf, formats and modifiers, and their usage. Signed-off-by: Daniel Stone Signed-off-by: Simon Ser Reviewed-by: Simon Ser Reviewed-by: Sui Jingfeng Acked-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20230803154908.105124-4-daniels@collabora.com --- Documentation/gpu/drm-uapi.rst | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation/gpu') diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 65fb3036a580..eef5fd19bc92 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -486,3 +486,10 @@ and the CRTC index is its position in this array. .. kernel-doc:: include/uapi/drm/drm_mode.h :internal: + + +dma-buf interoperability +======================== + +Please see Documentation/userspace-api/dma-buf-alloc-exchange.rst for +information on how dma-buf is integrated and exposed within DRM. -- cgit v1.2.3 From d29e112ab8d4fea3bf82c7b023c6e65ed2c0e5eb Mon Sep 17 00:00:00 2001 From: Rodrigo Vivi Date: Tue, 29 Aug 2023 12:30:01 -0400 Subject: drm/doc/rfc: No STAGING out of drivers/staging. Also the uapi should be reviewed and scrutinized before xe is accepted upstream and we shouldn't cause regression. Link: https://lore.kernel.org/all/20230630100059.122881-1-thomas.hellstrom@linux.intel.com Acked-by: Daniel Vetter Reviewed-by: Lucas De Marchi Signed-off-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20230829163005.54067-1-rodrigo.vivi@intel.com --- Documentation/gpu/rfc/xe.rst | 6 ------ 1 file changed, 6 deletions(-) (limited to 'Documentation/gpu') diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst index 2516fe141db6..3d2181bf3dad 100644 --- a/Documentation/gpu/rfc/xe.rst +++ b/Documentation/gpu/rfc/xe.rst @@ -67,12 +67,6 @@ platforms. When the time comes for Xe, the protection will be lifted on Xe and kept in i915. -Xe driver will be protected with both STAGING Kconfig and force_probe. Changes in -the uAPI are expected while the driver is behind these protections. STAGING will -be removed when the driver uAPI gets to a mature state where we can guarantee the -‘no regression’ rule. Then force_probe will be lifted only for future platforms -that will be productized with Xe driver, but not with i915. - Xe – Pre-Merge Goals ==================== -- cgit v1.2.3 From eed5d32ea1e2a02ba7f14f493263614121a429a3 Mon Sep 17 00:00:00 2001 From: Rodrigo Vivi Date: Tue, 29 Aug 2023 12:30:02 -0400 Subject: drm/doc/rfc: Mark Dev_coredump as completed. Xe is already using devcoredump infrastructure as the primary error state and all the changes needed for user space error replay and other useful logs are getting added into xe_devcoredump. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/blob/drm-xe-next/drivers/gpu/drm/xe/xe_devcoredump.c Signed-off-by: Rodrigo Vivi Acked-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20230829163005.54067-2-rodrigo.vivi@intel.com --- Documentation/gpu/rfc/xe.rst | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) (limited to 'Documentation/gpu') diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst index 3d2181bf3dad..bf60c5c82d0e 100644 --- a/Documentation/gpu/rfc/xe.rst +++ b/Documentation/gpu/rfc/xe.rst @@ -67,8 +67,8 @@ platforms. When the time comes for Xe, the protection will be lifted on Xe and kept in i915. -Xe – Pre-Merge Goals -==================== +Xe – Pre-Merge Goals - Work-in-Progress +======================================= Drm_scheduler ------------- @@ -206,6 +206,14 @@ This item ties into the GPUVA, VM_BIND, and even long-running compute support. As a key measurable result, we need to have a community consensus documented in this document and the Xe driver prepared for the changes, if necessary. +Xe – uAPI high level overview +============================= + +...Warning: To be done in follow up patches after/when/where the main consensus in various items are individually reached. + +Xe – Pre-Merge Goals - Completed +================================ + Dev_coredump ------------ @@ -222,8 +230,3 @@ Later, when we are in-tree, the goal is to collaborate with devcoredump infrastructure with overall possible improvements, like multiple file support for better organization of the dumps, snapshot support, dmesg extra print, and whatever may make sense and help the overall infrastructure. - -Xe – uAPI high level overview -============================= - -...Warning: To be done in follow up patches after/when/where the main consensus in various items are individually reached. -- cgit v1.2.3 From 3d06add933cc0ccb41cf4ba531216b144e12609f Mon Sep 17 00:00:00 2001 From: Rodrigo Vivi Date: Tue, 29 Aug 2023 12:30:03 -0400 Subject: drm/doc/rfc: Mark DRM_VM_BIND as complete. The consensus is for individual drivers VM_BIND uapis with the GPUVA helpers that are already implemented and merged upstream. The merged GPUVA documentation also establish some overall rules for the locking to be followed by the drivers. Signed-off-by: Rodrigo Vivi Acked-by: Daniel Vetter Acked-by: Danilo Krummrich Link: https://patchwork.freedesktop.org/patch/msgid/20230829163005.54067-3-rodrigo.vivi@intel.com --- Documentation/gpu/rfc/xe.rst | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) (limited to 'Documentation/gpu') diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst index bf60c5c82d0e..a115526c03e0 100644 --- a/Documentation/gpu/rfc/xe.rst +++ b/Documentation/gpu/rfc/xe.rst @@ -106,23 +106,6 @@ our tree. Missing Nouveau patches should *not* block Xe and any needed GPUVA related patch should be independent and present on dri-devel or acked by maintainers to go along with the first Xe pull request towards drm-next. -DRM_VM_BIND ------------ -Nouveau, and Xe are all implementing ‘VM_BIND’ and new ‘Exec’ uAPIs in order to -fulfill the needs of the modern uAPI. Xe merge should *not* be blocked on the -development of a common new drm_infrastructure. However, the Xe team needs to -engage with the community to explore the options of a common API. - -As a key measurable result, the DRM_VM_BIND needs to be documented in this file -below, or this entire block deleted if the consensus is for independent drivers -vm_bind ioctls. - -Although having a common DRM level IOCTL for VM_BIND is not a requirement to get -Xe merged, it is mandatory to enforce the overall locking scheme for all major -structs and list (so vm and vma). So, a consensus is needed, and possibly some -common helpers. If helpers are needed, they should be also documented in this -document. - ASYNC VM_BIND ------------- Although having a common DRM level IOCTL for VM_BIND is not a requirement to get @@ -230,3 +213,20 @@ Later, when we are in-tree, the goal is to collaborate with devcoredump infrastructure with overall possible improvements, like multiple file support for better organization of the dumps, snapshot support, dmesg extra print, and whatever may make sense and help the overall infrastructure. + +DRM_VM_BIND +----------- +Nouveau, and Xe are all implementing ‘VM_BIND’ and new ‘Exec’ uAPIs in order to +fulfill the needs of the modern uAPI. Xe merge should *not* be blocked on the +development of a common new drm_infrastructure. However, the Xe team needs to +engage with the community to explore the options of a common API. + +As a key measurable result, the DRM_VM_BIND needs to be documented in this file +below, or this entire block deleted if the consensus is for independent drivers +vm_bind ioctls. + +Although having a common DRM level IOCTL for VM_BIND is not a requirement to get +Xe merged, it is mandatory to enforce the overall locking scheme for all major +structs and list (so vm and vma). So, a consensus is needed, and possibly some +common helpers. If helpers are needed, they should be also documented in this +document. -- cgit v1.2.3 From e4a0fbdd85216d33b9d7ba5667210fd9a915e62b Mon Sep 17 00:00:00 2001 From: Rodrigo Vivi Date: Tue, 29 Aug 2023 12:30:04 -0400 Subject: drm/doc/rfc: Mark GPU VA as complete. Nouveau has landed the GPU VA helpers, support and documentation already and Xe is already using the upstream GPU VA. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/commit/ea4ae69e66b2940107e74f240ecb9dae87bf1ff1 Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/commits/drm-xe-next?ref_type=heads Signed-off-by: Rodrigo Vivi Acked-by: Daniel Vetter Acked-by: Danilo Krummrich Link: https://patchwork.freedesktop.org/patch/msgid/20230829163005.54067-4-rodrigo.vivi@intel.com --- Documentation/gpu/rfc/xe.rst | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) (limited to 'Documentation/gpu') diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst index a115526c03e0..b67f8e6a1825 100644 --- a/Documentation/gpu/rfc/xe.rst +++ b/Documentation/gpu/rfc/xe.rst @@ -88,24 +88,6 @@ depend on any other patch touching drm_scheduler itself that was not yet merged through drm-misc. This, by itself, already includes the reach of an agreement for uniform 1 to 1 relationship implementation / usage across drivers. -GPU VA ------- -Two main goals of Xe are meeting together here: - -1) Have an uAPI that aligns with modern UMD needs. - -2) Early upstream engagement. - -RedHat engineers working on Nouveau proposed a new DRM feature to handle keeping -track of GPU virtual address mappings. This is still not merged upstream, but -this aligns very well with our goals and with our VM_BIND. The engagement with -upstream and the port of Xe towards GPUVA is already ongoing. - -As a key measurable result, Xe needs to be aligned with the GPU VA and working in -our tree. Missing Nouveau patches should *not* block Xe and any needed GPUVA -related patch should be independent and present on dri-devel or acked by -maintainers to go along with the first Xe pull request towards drm-next. - ASYNC VM_BIND ------------- Although having a common DRM level IOCTL for VM_BIND is not a requirement to get @@ -230,3 +212,21 @@ Xe merged, it is mandatory to enforce the overall locking scheme for all major structs and list (so vm and vma). So, a consensus is needed, and possibly some common helpers. If helpers are needed, they should be also documented in this document. + +GPU VA +------ +Two main goals of Xe are meeting together here: + +1) Have an uAPI that aligns with modern UMD needs. + +2) Early upstream engagement. + +RedHat engineers working on Nouveau proposed a new DRM feature to handle keeping +track of GPU virtual address mappings. This is still not merged upstream, but +this aligns very well with our goals and with our VM_BIND. The engagement with +upstream and the port of Xe towards GPUVA is already ongoing. + +As a key measurable result, Xe needs to be aligned with the GPU VA and working in +our tree. Missing Nouveau patches should *not* block Xe and any needed GPUVA +related patch should be independent and present on dri-devel or acked by +maintainers to go along with the first Xe pull request towards drm-next. -- cgit v1.2.3