| Message ID | 20240110190427.63095-1-rodrigo.vivi@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/doc/rfc: Remove Xe's pre-merge plan | expand |
On Wed, Jan 10, 2024 at 02:04:27PM -0500, Rodrigo Vivi wrote: >The last TODO item here that was not marked as done was >the display portion, which came along with the pull-request. > >So, now that Xe is part of drm-next and it includes the >display portion, let's entirely kill this RFC here. > >Cc: Lucas De Marchi <lucas.demarchi@intel.com> >Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> >Cc: Oded Gabbay <ogabbay@kernel.org> >Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> thanks Lucas De Marchi >--- > Documentation/gpu/rfc/xe.rst | 234 ----------------------------------- > 1 file changed, 234 deletions(-) > delete mode 100644 Documentation/gpu/rfc/xe.rst > >diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst >deleted file mode 100644 >index 97cf87578f97..000000000000 >--- a/Documentation/gpu/rfc/xe.rst >+++ /dev/null >@@ -1,234 +0,0 @@ >-========================== >-Xe – Merge Acceptance Plan >-========================== >-Xe is a new driver for Intel GPUs that supports both integrated and >-discrete platforms starting with Tiger Lake (first Intel Xe Architecture). >- >-This document aims to establish a merge plan for the Xe, by writing down clear >-pre-merge goals, in order to avoid unnecessary delays. >- >-Xe – Overview >-============= >-The main motivation of Xe is to have a fresh base to work from that is >-unencumbered by older platforms, whilst also taking the opportunity to >-rearchitect our driver to increase sharing across the drm subsystem, both >-leveraging and allowing us to contribute more towards other shared components >-like TTM and drm/scheduler. >- >-This is also an opportunity to start from the beginning with a clean uAPI that is >-extensible by design and already aligned with the modern userspace needs. For >-this reason, the memory model is solely based on GPU Virtual Address space >-bind/unbind (‘VM_BIND’) of GEM buffer objects (BOs) and execution only supporting >-explicit synchronization. With persistent mapping across the execution, the >-userspace does not need to provide a list of all required mappings during each >-submission. >- >-The new driver leverages a lot from i915. As for display, the intent is to share >-the display code with the i915 driver so that there is maximum reuse there. >- >-As for the power management area, the goal is to have a much-simplified support >-for the system suspend states (S-states), PCI device suspend states (D-states), >-GPU/Render suspend states (R-states) and frequency management. It should leverage >-as much as possible all the existent PCI-subsystem infrastructure (pm and >-runtime_pm) and underlying firmware components such PCODE and GuC for the power >-states and frequency decisions. >- >-Repository: >- >-https://gitlab.freedesktop.org/drm/xe/kernel (branch drm-xe-next) >- >-Xe – Platforms >-============== >-Currently, Xe is already functional and has experimental support for multiple >-platforms starting from Tiger Lake, with initial support in userspace implemented >-in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in NEO >-(for OpenCL and Level0). >- >-During a transition period, platforms will be supported by both Xe and i915. >-However, the force_probe mechanism existent in both drivers will allow only one >-official and by-default probe at a given time. >- >-For instance, in order to probe a DG2 which PCI ID is 0x5690 by Xe instead of >-i915, the following set of parameters need to be used: >- >-``` >-i915.force_probe=!5690 xe.force_probe=5690 >-``` >- >-In both drivers, the ‘.require_force_probe’ protection forces the user to use the >-force_probe parameter while the driver is under development. This protection is >-only removed when the support for the platform and the uAPI are stable. Stability >-which needs to be demonstrated by CI results. >- >-In order to avoid user space regressions, i915 will continue to support all the >-current platforms that are already out of this protection. Xe support will be >-forever experimental and dependent on the usage of force_probe for these >-platforms. >- >-When the time comes for Xe, the protection will be lifted on Xe and kept in i915. >- >-Xe – Pre-Merge Goals - Work-in-Progress >-======================================= >- >-Display integration with i915 >------------------------------ >-In order to share the display code with the i915 driver so that there is maximum >-reuse, the i915/display/ code is built twice, once for i915.ko and then for >-xe.ko. Currently, the i915/display code in Xe tree is polluted with many 'ifdefs' >-depending on the build target. The goal is to refactor both Xe and i915/display >-code simultaneously in order to get a clean result before they land upstream, so >-that display can already be part of the initial pull request towards drm-next. >- >-However, display code should not gate the acceptance of Xe in upstream. Xe >-patches will be refactored in a way that display code can be removed, if needed, >-from the first pull request of Xe towards drm-next. The expectation is that when >-both drivers are part of the drm-tip, the introduction of cleaner patches will be >-easier and speed up. >- >-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 >-================================ >- >-Drm_exec >--------- >-Helper to make dma_resv locking for a big number of buffers is getting removed in >-the drm_exec series proposed in https://patchwork.freedesktop.org/patch/524376/ >-If that happens, Xe needs to change and incorporate the changes in the driver. >-The goal is to engage with the Community to understand if the best approach is to >-move that to the drivers that are using it or if we should keep the helpers in >-place waiting for Xe to get merged. >- >-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. >- >-Userptr integration and vm_bind >-------------------------------- >-Different drivers implement different ways of dealing with execution of userptr. >-With multiple drivers currently introducing support to VM_BIND, the goal is to >-aim for a DRM consensus on what’s the best way to have that support. To some >-extent this is already getting addressed itself with the GPUVA where likely the >-userptr will be a GPUVA with a NULL GEM call VM bind directly on the userptr. >-However, there are more aspects around the rules for that and the usage of >-mmu_notifiers, locking and other aspects. >- >-This task here has the goal of introducing a documentation of the basic rules. >- >-The documentation *needs* to first live in this document (API session below) and >-then moved to another more specific document or at Xe level or at DRM level. >- >-Documentation should include: >- >- * The userptr part of the VM_BIND api. >- >- * Locking, including the page-faulting case. >- >- * O(1) complexity under VM_BIND. >- >-The document is now included in the drm documentation :doc:`here </gpu/drm-vm-bind-async>`. >- >-Some parts of userptr like mmu_notifiers should become GPUVA or DRM helpers when >-the second driver supporting VM_BIND+userptr appears. Details to be defined when >-the time comes. >- >-The DRM GPUVM helpers do not yet include the userptr parts, but discussions >-about implementing them are ongoing. >- >-ASYNC VM_BIND >-------------- >-Although having a common DRM level IOCTL for VM_BIND is not a requirement to get >-Xe merged, it is mandatory to have a consensus with other drivers and Mesa. >-It needs to be clear how to handle async VM_BIND and interactions with userspace >-memory fences. Ideally with helper support so people don't get it wrong in all >-possible ways. >- >-As a key measurable result, the benefits of ASYNC VM_BIND and a discussion of >-various flavors, error handling and sample API suggestions are documented in >-:doc:`The ASYNC VM_BIND document </gpu/drm-vm-bind-async>`. >- >-Drm_scheduler >-------------- >-Xe primarily uses Firmware based scheduling (GuC FW). However, it will use >-drm_scheduler as the scheduler ‘frontend’ for userspace submission in order to >-resolve syncobj and dma-buf implicit sync dependencies. However, drm_scheduler is >-not yet prepared to handle the 1-to-1 relationship between drm_gpu_scheduler and >-drm_sched_entity. >- >-Deeper changes to drm_scheduler should *not* be required to get Xe accepted, but >-some consensus needs to be reached between Xe and other community drivers that >-could also benefit from this work, for coupling FW based/assisted submission such >-as the ARM’s new Mali GPU driver, and others. >- >-As a key measurable result, the patch series introducing Xe itself shall not >-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. >- >-Long running compute: minimal data structure/scaffolding >--------------------------------------------------------- >-The generic scheduler code needs to include the handling of endless compute >-contexts, with the minimal scaffolding for preempt-ctx fences (probably on the >-drm_sched_entity) and making sure drm_scheduler can cope with the lack of job >-completion fence. >- >-The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with >-this minimal drm/scheduler work, if needed, merged to drm-misc in a way that any >-drm driver, including Xe, could re-use and add their own individual needs on top >-in a next stage. However, this should not block the initial merge. >- >-Dev_coredump >------------- >- >-Xe needs to align with other drivers on the way that the error states are >-dumped, avoiding a Xe only error_state solution. The goal is to use devcoredump >-infrastructure to report error states, since it produces a standardized way >-by exposing a virtual and temporary /sys/class/devcoredump device. >- >-As the key measurable result, Xe driver needs to provide GPU snapshots captured >-at hang time through devcoredump, but without depending on any core modification >-of devcoredump infrastructure itself. >- >-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. >- >-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. >-- >2.43.0 >
On Wed, Jan 10, 2024 at 02:07:38PM -0600, Lucas De Marchi wrote: > On Wed, Jan 10, 2024 at 02:04:27PM -0500, Rodrigo Vivi wrote: > > The last TODO item here that was not marked as done was > > the display portion, which came along with the pull-request. > > > > So, now that Xe is part of drm-next and it includes the > > display portion, let's entirely kill this RFC here. > > > > Cc: Lucas De Marchi <lucas.demarchi@intel.com> > > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> > > Cc: Oded Gabbay <ogabbay@kernel.org> > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > > Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Thanks, pushed to drm-misc-next. > > thanks > Lucas De Marchi > > > --- > > Documentation/gpu/rfc/xe.rst | 234 ----------------------------------- > > 1 file changed, 234 deletions(-) > > delete mode 100644 Documentation/gpu/rfc/xe.rst > > > > diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst > > deleted file mode 100644 > > index 97cf87578f97..000000000000 > > --- a/Documentation/gpu/rfc/xe.rst > > +++ /dev/null > > @@ -1,234 +0,0 @@ > > -========================== > > -Xe – Merge Acceptance Plan > > -========================== > > -Xe is a new driver for Intel GPUs that supports both integrated and > > -discrete platforms starting with Tiger Lake (first Intel Xe Architecture). > > - > > -This document aims to establish a merge plan for the Xe, by writing down clear > > -pre-merge goals, in order to avoid unnecessary delays. > > - > > -Xe – Overview > > -============= > > -The main motivation of Xe is to have a fresh base to work from that is > > -unencumbered by older platforms, whilst also taking the opportunity to > > -rearchitect our driver to increase sharing across the drm subsystem, both > > -leveraging and allowing us to contribute more towards other shared components > > -like TTM and drm/scheduler. > > - > > -This is also an opportunity to start from the beginning with a clean uAPI that is > > -extensible by design and already aligned with the modern userspace needs. For > > -this reason, the memory model is solely based on GPU Virtual Address space > > -bind/unbind (‘VM_BIND’) of GEM buffer objects (BOs) and execution only supporting > > -explicit synchronization. With persistent mapping across the execution, the > > -userspace does not need to provide a list of all required mappings during each > > -submission. > > - > > -The new driver leverages a lot from i915. As for display, the intent is to share > > -the display code with the i915 driver so that there is maximum reuse there. > > - > > -As for the power management area, the goal is to have a much-simplified support > > -for the system suspend states (S-states), PCI device suspend states (D-states), > > -GPU/Render suspend states (R-states) and frequency management. It should leverage > > -as much as possible all the existent PCI-subsystem infrastructure (pm and > > -runtime_pm) and underlying firmware components such PCODE and GuC for the power > > -states and frequency decisions. > > - > > -Repository: > > - > > -https://gitlab.freedesktop.org/drm/xe/kernel (branch drm-xe-next) > > - > > -Xe – Platforms > > -============== > > -Currently, Xe is already functional and has experimental support for multiple > > -platforms starting from Tiger Lake, with initial support in userspace implemented > > -in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in NEO > > -(for OpenCL and Level0). > > - > > -During a transition period, platforms will be supported by both Xe and i915. > > -However, the force_probe mechanism existent in both drivers will allow only one > > -official and by-default probe at a given time. > > - > > -For instance, in order to probe a DG2 which PCI ID is 0x5690 by Xe instead of > > -i915, the following set of parameters need to be used: > > - > > -``` > > -i915.force_probe=!5690 xe.force_probe=5690 > > -``` > > - > > -In both drivers, the ‘.require_force_probe’ protection forces the user to use the > > -force_probe parameter while the driver is under development. This protection is > > -only removed when the support for the platform and the uAPI are stable. Stability > > -which needs to be demonstrated by CI results. > > - > > -In order to avoid user space regressions, i915 will continue to support all the > > -current platforms that are already out of this protection. Xe support will be > > -forever experimental and dependent on the usage of force_probe for these > > -platforms. > > - > > -When the time comes for Xe, the protection will be lifted on Xe and kept in i915. > > - > > -Xe – Pre-Merge Goals - Work-in-Progress > > -======================================= > > - > > -Display integration with i915 > > ------------------------------ > > -In order to share the display code with the i915 driver so that there is maximum > > -reuse, the i915/display/ code is built twice, once for i915.ko and then for > > -xe.ko. Currently, the i915/display code in Xe tree is polluted with many 'ifdefs' > > -depending on the build target. The goal is to refactor both Xe and i915/display > > -code simultaneously in order to get a clean result before they land upstream, so > > -that display can already be part of the initial pull request towards drm-next. > > - > > -However, display code should not gate the acceptance of Xe in upstream. Xe > > -patches will be refactored in a way that display code can be removed, if needed, > > -from the first pull request of Xe towards drm-next. The expectation is that when > > -both drivers are part of the drm-tip, the introduction of cleaner patches will be > > -easier and speed up. > > - > > -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 > > -================================ > > - > > -Drm_exec > > --------- > > -Helper to make dma_resv locking for a big number of buffers is getting removed in > > -the drm_exec series proposed in https://patchwork.freedesktop.org/patch/524376/ > > -If that happens, Xe needs to change and incorporate the changes in the driver. > > -The goal is to engage with the Community to understand if the best approach is to > > -move that to the drivers that are using it or if we should keep the helpers in > > -place waiting for Xe to get merged. > > - > > -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. > > - > > -Userptr integration and vm_bind > > -------------------------------- > > -Different drivers implement different ways of dealing with execution of userptr. > > -With multiple drivers currently introducing support to VM_BIND, the goal is to > > -aim for a DRM consensus on what’s the best way to have that support. To some > > -extent this is already getting addressed itself with the GPUVA where likely the > > -userptr will be a GPUVA with a NULL GEM call VM bind directly on the userptr. > > -However, there are more aspects around the rules for that and the usage of > > -mmu_notifiers, locking and other aspects. > > - > > -This task here has the goal of introducing a documentation of the basic rules. > > - > > -The documentation *needs* to first live in this document (API session below) and > > -then moved to another more specific document or at Xe level or at DRM level. > > - > > -Documentation should include: > > - > > - * The userptr part of the VM_BIND api. > > - > > - * Locking, including the page-faulting case. > > - > > - * O(1) complexity under VM_BIND. > > - > > -The document is now included in the drm documentation :doc:`here </gpu/drm-vm-bind-async>`. > > - > > -Some parts of userptr like mmu_notifiers should become GPUVA or DRM helpers when > > -the second driver supporting VM_BIND+userptr appears. Details to be defined when > > -the time comes. > > - > > -The DRM GPUVM helpers do not yet include the userptr parts, but discussions > > -about implementing them are ongoing. > > - > > -ASYNC VM_BIND > > -------------- > > -Although having a common DRM level IOCTL for VM_BIND is not a requirement to get > > -Xe merged, it is mandatory to have a consensus with other drivers and Mesa. > > -It needs to be clear how to handle async VM_BIND and interactions with userspace > > -memory fences. Ideally with helper support so people don't get it wrong in all > > -possible ways. > > - > > -As a key measurable result, the benefits of ASYNC VM_BIND and a discussion of > > -various flavors, error handling and sample API suggestions are documented in > > -:doc:`The ASYNC VM_BIND document </gpu/drm-vm-bind-async>`. > > - > > -Drm_scheduler > > -------------- > > -Xe primarily uses Firmware based scheduling (GuC FW). However, it will use > > -drm_scheduler as the scheduler ‘frontend’ for userspace submission in order to > > -resolve syncobj and dma-buf implicit sync dependencies. However, drm_scheduler is > > -not yet prepared to handle the 1-to-1 relationship between drm_gpu_scheduler and > > -drm_sched_entity. > > - > > -Deeper changes to drm_scheduler should *not* be required to get Xe accepted, but > > -some consensus needs to be reached between Xe and other community drivers that > > -could also benefit from this work, for coupling FW based/assisted submission such > > -as the ARM’s new Mali GPU driver, and others. > > - > > -As a key measurable result, the patch series introducing Xe itself shall not > > -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. > > - > > -Long running compute: minimal data structure/scaffolding > > --------------------------------------------------------- > > -The generic scheduler code needs to include the handling of endless compute > > -contexts, with the minimal scaffolding for preempt-ctx fences (probably on the > > -drm_sched_entity) and making sure drm_scheduler can cope with the lack of job > > -completion fence. > > - > > -The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with > > -this minimal drm/scheduler work, if needed, merged to drm-misc in a way that any > > -drm driver, including Xe, could re-use and add their own individual needs on top > > -in a next stage. However, this should not block the initial merge. > > - > > -Dev_coredump > > ------------- > > - > > -Xe needs to align with other drivers on the way that the error states are > > -dumped, avoiding a Xe only error_state solution. The goal is to use devcoredump > > -infrastructure to report error states, since it produces a standardized way > > -by exposing a virtual and temporary /sys/class/devcoredump device. > > - > > -As the key measurable result, Xe driver needs to provide GPU snapshots captured > > -at hang time through devcoredump, but without depending on any core modification > > -of devcoredump infrastructure itself. > > - > > -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. > > - > > -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. > > -- > > 2.43.0 > >
diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst deleted file mode 100644 index 97cf87578f97..000000000000 --- a/Documentation/gpu/rfc/xe.rst +++ /dev/null @@ -1,234 +0,0 @@ -========================== -Xe – Merge Acceptance Plan -========================== -Xe is a new driver for Intel GPUs that supports both integrated and -discrete platforms starting with Tiger Lake (first Intel Xe Architecture). - -This document aims to establish a merge plan for the Xe, by writing down clear -pre-merge goals, in order to avoid unnecessary delays. - -Xe – Overview -============= -The main motivation of Xe is to have a fresh base to work from that is -unencumbered by older platforms, whilst also taking the opportunity to -rearchitect our driver to increase sharing across the drm subsystem, both -leveraging and allowing us to contribute more towards other shared components -like TTM and drm/scheduler. - -This is also an opportunity to start from the beginning with a clean uAPI that is -extensible by design and already aligned with the modern userspace needs. For -this reason, the memory model is solely based on GPU Virtual Address space -bind/unbind (‘VM_BIND’) of GEM buffer objects (BOs) and execution only supporting -explicit synchronization. With persistent mapping across the execution, the -userspace does not need to provide a list of all required mappings during each -submission. - -The new driver leverages a lot from i915. As for display, the intent is to share -the display code with the i915 driver so that there is maximum reuse there. - -As for the power management area, the goal is to have a much-simplified support -for the system suspend states (S-states), PCI device suspend states (D-states), -GPU/Render suspend states (R-states) and frequency management. It should leverage -as much as possible all the existent PCI-subsystem infrastructure (pm and -runtime_pm) and underlying firmware components such PCODE and GuC for the power -states and frequency decisions. - -Repository: - -https://gitlab.freedesktop.org/drm/xe/kernel (branch drm-xe-next) - -Xe – Platforms -============== -Currently, Xe is already functional and has experimental support for multiple -platforms starting from Tiger Lake, with initial support in userspace implemented -in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in NEO -(for OpenCL and Level0). - -During a transition period, platforms will be supported by both Xe and i915. -However, the force_probe mechanism existent in both drivers will allow only one -official and by-default probe at a given time. - -For instance, in order to probe a DG2 which PCI ID is 0x5690 by Xe instead of -i915, the following set of parameters need to be used: - -``` -i915.force_probe=!5690 xe.force_probe=5690 -``` - -In both drivers, the ‘.require_force_probe’ protection forces the user to use the -force_probe parameter while the driver is under development. This protection is -only removed when the support for the platform and the uAPI are stable. Stability -which needs to be demonstrated by CI results. - -In order to avoid user space regressions, i915 will continue to support all the -current platforms that are already out of this protection. Xe support will be -forever experimental and dependent on the usage of force_probe for these -platforms. - -When the time comes for Xe, the protection will be lifted on Xe and kept in i915. - -Xe – Pre-Merge Goals - Work-in-Progress -======================================= - -Display integration with i915 ------------------------------ -In order to share the display code with the i915 driver so that there is maximum -reuse, the i915/display/ code is built twice, once for i915.ko and then for -xe.ko. Currently, the i915/display code in Xe tree is polluted with many 'ifdefs' -depending on the build target. The goal is to refactor both Xe and i915/display -code simultaneously in order to get a clean result before they land upstream, so -that display can already be part of the initial pull request towards drm-next. - -However, display code should not gate the acceptance of Xe in upstream. Xe -patches will be refactored in a way that display code can be removed, if needed, -from the first pull request of Xe towards drm-next. The expectation is that when -both drivers are part of the drm-tip, the introduction of cleaner patches will be -easier and speed up. - -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 -================================ - -Drm_exec --------- -Helper to make dma_resv locking for a big number of buffers is getting removed in -the drm_exec series proposed in https://patchwork.freedesktop.org/patch/524376/ -If that happens, Xe needs to change and incorporate the changes in the driver. -The goal is to engage with the Community to understand if the best approach is to -move that to the drivers that are using it or if we should keep the helpers in -place waiting for Xe to get merged. - -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. - -Userptr integration and vm_bind -------------------------------- -Different drivers implement different ways of dealing with execution of userptr. -With multiple drivers currently introducing support to VM_BIND, the goal is to -aim for a DRM consensus on what’s the best way to have that support. To some -extent this is already getting addressed itself with the GPUVA where likely the -userptr will be a GPUVA with a NULL GEM call VM bind directly on the userptr. -However, there are more aspects around the rules for that and the usage of -mmu_notifiers, locking and other aspects. - -This task here has the goal of introducing a documentation of the basic rules. - -The documentation *needs* to first live in this document (API session below) and -then moved to another more specific document or at Xe level or at DRM level. - -Documentation should include: - - * The userptr part of the VM_BIND api. - - * Locking, including the page-faulting case. - - * O(1) complexity under VM_BIND. - -The document is now included in the drm documentation :doc:`here </gpu/drm-vm-bind-async>`. - -Some parts of userptr like mmu_notifiers should become GPUVA or DRM helpers when -the second driver supporting VM_BIND+userptr appears. Details to be defined when -the time comes. - -The DRM GPUVM helpers do not yet include the userptr parts, but discussions -about implementing them are ongoing. - -ASYNC VM_BIND -------------- -Although having a common DRM level IOCTL for VM_BIND is not a requirement to get -Xe merged, it is mandatory to have a consensus with other drivers and Mesa. -It needs to be clear how to handle async VM_BIND and interactions with userspace -memory fences. Ideally with helper support so people don't get it wrong in all -possible ways. - -As a key measurable result, the benefits of ASYNC VM_BIND and a discussion of -various flavors, error handling and sample API suggestions are documented in -:doc:`The ASYNC VM_BIND document </gpu/drm-vm-bind-async>`. - -Drm_scheduler -------------- -Xe primarily uses Firmware based scheduling (GuC FW). However, it will use -drm_scheduler as the scheduler ‘frontend’ for userspace submission in order to -resolve syncobj and dma-buf implicit sync dependencies. However, drm_scheduler is -not yet prepared to handle the 1-to-1 relationship between drm_gpu_scheduler and -drm_sched_entity. - -Deeper changes to drm_scheduler should *not* be required to get Xe accepted, but -some consensus needs to be reached between Xe and other community drivers that -could also benefit from this work, for coupling FW based/assisted submission such -as the ARM’s new Mali GPU driver, and others. - -As a key measurable result, the patch series introducing Xe itself shall not -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. - -Long running compute: minimal data structure/scaffolding --------------------------------------------------------- -The generic scheduler code needs to include the handling of endless compute -contexts, with the minimal scaffolding for preempt-ctx fences (probably on the -drm_sched_entity) and making sure drm_scheduler can cope with the lack of job -completion fence. - -The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with -this minimal drm/scheduler work, if needed, merged to drm-misc in a way that any -drm driver, including Xe, could re-use and add their own individual needs on top -in a next stage. However, this should not block the initial merge. - -Dev_coredump ------------- - -Xe needs to align with other drivers on the way that the error states are -dumped, avoiding a Xe only error_state solution. The goal is to use devcoredump -infrastructure to report error states, since it produces a standardized way -by exposing a virtual and temporary /sys/class/devcoredump device. - -As the key measurable result, Xe driver needs to provide GPU snapshots captured -at hang time through devcoredump, but without depending on any core modification -of devcoredump infrastructure itself. - -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. - -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.
The last TODO item here that was not marked as done was the display portion, which came along with the pull-request. So, now that Xe is part of drm-next and it includes the display portion, let's entirely kill this RFC here. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> --- Documentation/gpu/rfc/xe.rst | 234 ----------------------------------- 1 file changed, 234 deletions(-) delete mode 100644 Documentation/gpu/rfc/xe.rst