| Message ID | 20230829163005.54067-4-rodrigo.vivi@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/4] drm/doc/rfc: No STAGING out of drivers/staging. | expand |
On Tue, Aug 29, 2023 at 12:30:04PM -0400, Rodrigo Vivi wrote: > Nouveau has landed the GPU VA helpers, support and documentation > already and Xe is already using the upstream GPU VA. Danilo, although this is more on the Xe side and I wouldn't ask you to review our code entirely, I'd like to get your ack here as Daniel recommended. Meaning that we are aligned there and not creating any change on top of GPU VA. Xe is currently using GPU VA directly without any customization. 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 <rodrigo.vivi@intel.com> > --- > Documentation/gpu/rfc/xe.rst | 36 ++++++++++++++++++------------------ > 1 file changed, 18 insertions(+), 18 deletions(-) > > 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. > -- > 2.41.0 >
On 8/31/23 21:17, Rodrigo Vivi wrote: > On Tue, Aug 29, 2023 at 12:30:04PM -0400, Rodrigo Vivi wrote: >> Nouveau has landed the GPU VA helpers, support and documentation >> already and Xe is already using the upstream GPU VA. > > Danilo, although this is more on the Xe side and I wouldn't ask you > to review our code entirely, I'd like to get your ack here as Daniel > recommended. Meaning that we are aligned there and not creating any > change on top of GPU VA. Xe is currently using GPU VA directly without > any customization. > > 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 Acked-by: Danilo Krummrich <dakr@redhat.com> Just one note: If we end up to agree on [1] few more adjustments are needed. Otherwise, same as the other commit, where is the paragraph going? - Danilo [1] https://lore.kernel.org/dri-devel/202308221050.kTj8uFMA-lkp@intel.com/T/#m7f3b5a7ff70723332adeea32671578cb95c62f7c > >> >> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> >> --- >> Documentation/gpu/rfc/xe.rst | 36 ++++++++++++++++++------------------ >> 1 file changed, 18 insertions(+), 18 deletions(-) >> >> 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. >> -- >> 2.41.0 >> >
On Mon, Sep 04, 2023 at 11:39:55PM +0200, Danilo Krummrich wrote: > On 8/31/23 21:17, Rodrigo Vivi wrote: > > On Tue, Aug 29, 2023 at 12:30:04PM -0400, Rodrigo Vivi wrote: > > > Nouveau has landed the GPU VA helpers, support and documentation > > > already and Xe is already using the upstream GPU VA. > > > > Danilo, although this is more on the Xe side and I wouldn't ask you > > to review our code entirely, I'd like to get your ack here as Daniel > > recommended. Meaning that we are aligned there and not creating any > > change on top of GPU VA. Xe is currently using GPU VA directly without > > any customization. > > > > 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 > > Acked-by: Danilo Krummrich <dakr@redhat.com> > > Just one note: If we end up to agree on [1] few more adjustments are needed. Thanks. I see Thomas is already engaged there and I believe it will be easier to change that and align when we are merged. Since that appears to not break any uapi. > > Otherwise, same as the other commit, where is the paragraph going? to the new +Xe – Pre-Merge Goals - Completed +================================ https://lore.kernel.org/all/20230829163005.54067-2-rodrigo.vivi@intel.com/ > > - Danilo > > [1] https://lore.kernel.org/dri-devel/202308221050.kTj8uFMA-lkp@intel.com/T/#m7f3b5a7ff70723332adeea32671578cb95c62f7c > > > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > > --- > > > Documentation/gpu/rfc/xe.rst | 36 ++++++++++++++++++------------------ > > > 1 file changed, 18 insertions(+), 18 deletions(-) > > > > > > 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. > > > -- > > > 2.41.0 > > > > > >
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.
Nouveau has landed the GPU VA helpers, support and documentation already and Xe is already using the upstream GPU VA. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> --- Documentation/gpu/rfc/xe.rst | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-)