Re: [Intel-gfx] [RFC v1] Data port coherency control for UMDs.
We don’t have any timeline for this at the moment. NEO driver is quite fresh in open source and adoption will be handled in near future. Can we move on with review process and handle adoption in separate thread? Thanks, Bartosz -Original Message- From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] Sent: Wednesday, April 4, 2018 11:19 AM To: Dunajski, Bartosz ; Ewins, Jon ; Lis, Tomasz ; intel-gfx@lists.freedesktop.org; Dave Airlie Cc: ch...@chris-wilson.co.uk; Winiarski, Michal Subject: RE: [RFC v1] Data port coherency control for UMDs. Quoting Dunajski, Bartosz (2018-03-30 12:00:51) > I think the adoption is not a problem here. Adoption is important for fulfilling the DRM subsystem requirements for merging new kernel uAPI that I referred to previously. So do we have some timeline for any distro picking up the new driver? Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v1] Data port coherency control for UMDs.
Quoting Dunajski, Bartosz (2018-03-30 12:00:51) > I think the adoption is not a problem here. Adoption is important for fulfilling the DRM subsystem requirements for merging new kernel uAPI that I referred to previously. So do we have some timeline for any distro picking up the new driver? Regards, Joonas > If driver can query that patch is active on the specific setup, new > capabilities will be always reported to the user. > > -Original Message- > Quoting Dunajski, Bartosz (2018-03-26 12:46:13) > > Here is pull request with patch usage: > > https://github.com/intel/compute-runtime/pull/29 > > > > This patch is required to control data port coherency depending on incoming > > workload into OpenCL API (fine-grain SVM requirement). > > Thank you for correcting the process. > > The original question however remains unanswered, how is it looking for the > adoption of the new driver in distros? > > I was not able to find much by searching online, but by looking at the > sources, I'd assume requiring a custom version of LLVM would be something to > get rid of. > > Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v1] Data port coherency control for UMDs.
I think the adoption is not a problem here. If driver can query that patch is active on the specific setup, new capabilities will be always reported to the user. -Original Message- Quoting Dunajski, Bartosz (2018-03-26 12:46:13) > Here is pull request with patch usage: > https://github.com/intel/compute-runtime/pull/29 > > This patch is required to control data port coherency depending on incoming > workload into OpenCL API (fine-grain SVM requirement). Thank you for correcting the process. The original question however remains unanswered, how is it looking for the adoption of the new driver in distros? I was not able to find much by searching online, but by looking at the sources, I'd assume requiring a custom version of LLVM would be something to get rid of. Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v1] Data port coherency control for UMDs.
Quoting Dunajski, Bartosz (2018-03-26 12:46:13) > Here is pull request with patch usage: > https://github.com/intel/compute-runtime/pull/29 > > This patch is required to control data port coherency depending on incoming > workload into OpenCL API (fine-grain SVM requirement). Thank you for correcting the process. The original question however remains unanswered, how is it looking for the adoption of the new driver in distros? I was not able to find much by searching online, but by looking at the sources, I'd assume requiring a custom version of LLVM would be something to get rid of. Regards, Joonas > > > -Original Message- > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Wednesday, March 21, 2018 11:03 AM > To: Dunajski, Bartosz ; Lis, Tomasz > ; intel-gfx@lists.freedesktop.org; Dave Airlie > ; Ewins, Jon > Cc: ch...@chris-wilson.co.uk; Winiarski, Michal > Subject: RE: [RFC v1] Data port coherency control for UMDs. > > + Jon, as we clearly have a disconnect between what was requested to be > done and what has been done. > > Quoting Dunajski, Bartosz (2018-03-20 17:15:06) > > This functionality is used by new OCL drvier (aka. NEO): > > https://github.com/intel/compute-runtime > > > > Starting from commit: 933312e0986d3a7c1ef557e511eb4ced301ea292 > > That's not how the changes were requested to be introduced. It's the opposite > of what was asked. > > You should do such changes in a topic branch, not the master. The master > branch must always be using only what is in the latest upstream kernel. > > Please read: > > https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements > > Paying special attention to: > > "The kernel patch can only be merged after all the above requirements are > met, but it must be merged before the userspace patches land. uAPI always > flows from the kernel, doing things the other way round risks divergence of > the uAPI definitions and header files." > > The end-user should always be able to update to the latest bleeding edge > kernel without userspace breakage. That's not the case here because the > userspace is tied to special kernel version so the ABI is bound to break. > > Regards, Joonas > > > > > -Original Message- > > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > > Sent: Monday, March 19, 2018 2:54 PM > > To: Lis, Tomasz ; > > intel-gfx@lists.freedesktop.org; Dave Airlie > > Cc: Dunajski, Bartosz ; > > ch...@chris-wilson.co.uk; Winiarski, Michal > > > > Subject: Re: [RFC v1] Data port coherency control for UMDs. > > > > + Dave, as FYI > > > > Quoting Tomasz Lis (2018-03-19 14:37:34) > > > The OpenCL driver develpers requested a functionality to control > > > cache coherency at data port level. Keeping the coherency at that > > > level is disabled by default due to its performance costs. OpenCL > > > driver is planning to enable it for a small subset of submissions, > > > when such functionality is required. > > > > Can you please link to the corresponding OpenCL driver changes? I'm > > assuming this relates to the new-driver-to-be-adopted, instead of Beignet? > > > > How is the story/schedule looking for adopting the new driver to distros? > > > > Seeing the userspace counterpart and tests will help in assessing the > > suggested changes. > > > > Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v1] Data port coherency control for UMDs.
Here is pull request with patch usage: https://github.com/intel/compute-runtime/pull/29 This patch is required to control data port coherency depending on incoming workload into OpenCL API (fine-grain SVM requirement). -Original Message- From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] Sent: Wednesday, March 21, 2018 11:03 AM To: Dunajski, Bartosz ; Lis, Tomasz ; intel-gfx@lists.freedesktop.org; Dave Airlie ; Ewins, Jon Cc: ch...@chris-wilson.co.uk; Winiarski, Michal Subject: RE: [RFC v1] Data port coherency control for UMDs. + Jon, as we clearly have a disconnect between what was requested to be done and what has been done. Quoting Dunajski, Bartosz (2018-03-20 17:15:06) > This functionality is used by new OCL drvier (aka. NEO): > https://github.com/intel/compute-runtime > > Starting from commit: 933312e0986d3a7c1ef557e511eb4ced301ea292 That's not how the changes were requested to be introduced. It's the opposite of what was asked. You should do such changes in a topic branch, not the master. The master branch must always be using only what is in the latest upstream kernel. Please read: https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements Paying special attention to: "The kernel patch can only be merged after all the above requirements are met, but it must be merged before the userspace patches land. uAPI always flows from the kernel, doing things the other way round risks divergence of the uAPI definitions and header files." The end-user should always be able to update to the latest bleeding edge kernel without userspace breakage. That's not the case here because the userspace is tied to special kernel version so the ABI is bound to break. Regards, Joonas > > -Original Message- > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Monday, March 19, 2018 2:54 PM > To: Lis, Tomasz ; > intel-gfx@lists.freedesktop.org; Dave Airlie > Cc: Dunajski, Bartosz ; > ch...@chris-wilson.co.uk; Winiarski, Michal > > Subject: Re: [RFC v1] Data port coherency control for UMDs. > > + Dave, as FYI > > Quoting Tomasz Lis (2018-03-19 14:37:34) > > The OpenCL driver develpers requested a functionality to control > > cache coherency at data port level. Keeping the coherency at that > > level is disabled by default due to its performance costs. OpenCL > > driver is planning to enable it for a small subset of submissions, > > when such functionality is required. > > Can you please link to the corresponding OpenCL driver changes? I'm assuming > this relates to the new-driver-to-be-adopted, instead of Beignet? > > How is the story/schedule looking for adopting the new driver to distros? > > Seeing the userspace counterpart and tests will help in assessing the > suggested changes. > > Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v1] Data port coherency control for UMDs.
+ Jon, as we clearly have a disconnect between what was requested to be done and what has been done. Quoting Dunajski, Bartosz (2018-03-20 17:15:06) > This functionality is used by new OCL drvier (aka. NEO): > https://github.com/intel/compute-runtime > > Starting from commit: 933312e0986d3a7c1ef557e511eb4ced301ea292 That's not how the changes were requested to be introduced. It's the opposite of what was asked. You should do such changes in a topic branch, not the master. The master branch must always be using only what is in the latest upstream kernel. Please read: https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements Paying special attention to: "The kernel patch can only be merged after all the above requirements are met, but it must be merged before the userspace patches land. uAPI always flows from the kernel, doing things the other way round risks divergence of the uAPI definitions and header files." The end-user should always be able to update to the latest bleeding edge kernel without userspace breakage. That's not the case here because the userspace is tied to special kernel version so the ABI is bound to break. Regards, Joonas > > -Original Message- > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Monday, March 19, 2018 2:54 PM > To: Lis, Tomasz ; intel-gfx@lists.freedesktop.org; Dave > Airlie > Cc: Dunajski, Bartosz ; ch...@chris-wilson.co.uk; > Winiarski, Michal > Subject: Re: [RFC v1] Data port coherency control for UMDs. > > + Dave, as FYI > > Quoting Tomasz Lis (2018-03-19 14:37:34) > > The OpenCL driver develpers requested a functionality to control cache > > coherency at data port level. Keeping the coherency at that level is > > disabled by default due to its performance costs. OpenCL driver is > > planning to enable it for a small subset of submissions, when such > > functionality is required. > > Can you please link to the corresponding OpenCL driver changes? I'm assuming > this relates to the new-driver-to-be-adopted, instead of Beignet? > > How is the story/schedule looking for adopting the new driver to distros? > > Seeing the userspace counterpart and tests will help in assessing the > suggested changes. > > Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v1] Data port coherency control for UMDs.
This functionality is used by new OCL drvier (aka. NEO): https://github.com/intel/compute-runtime Starting from commit: 933312e0986d3a7c1ef557e511eb4ced301ea292 -Original Message- From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] Sent: Monday, March 19, 2018 2:54 PM To: Lis, Tomasz ; intel-gfx@lists.freedesktop.org; Dave Airlie Cc: Dunajski, Bartosz ; ch...@chris-wilson.co.uk; Winiarski, Michal Subject: Re: [RFC v1] Data port coherency control for UMDs. + Dave, as FYI Quoting Tomasz Lis (2018-03-19 14:37:34) > The OpenCL driver develpers requested a functionality to control cache > coherency at data port level. Keeping the coherency at that level is > disabled by default due to its performance costs. OpenCL driver is > planning to enable it for a small subset of submissions, when such > functionality is required. Can you please link to the corresponding OpenCL driver changes? I'm assuming this relates to the new-driver-to-be-adopted, instead of Beignet? How is the story/schedule looking for adopting the new driver to distros? Seeing the userspace counterpart and tests will help in assessing the suggested changes. Regards, Joonas Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN. Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v1] Data port coherency control for UMDs.
On 2018-03-19 14:53, Joonas Lahtinen wrote: + Dave, as FYI Quoting Tomasz Lis (2018-03-19 14:37:34) The OpenCL driver develpers requested a functionality to control cache coherency at data port level. Keeping the coherency at that level is disabled by default due to its performance costs. OpenCL driver is planning to enable it for a small subset of submissions, when such functionality is required. Can you please link to the corresponding OpenCL driver changes? I'm assuming this relates to the new-driver-to-be-adopted, instead of Beignet? It is for the new driver; I will ask the OCL developers to provide a link. How is the story/schedule looking for adopting the new driver to distros? I guess that's another question for OCL guys, I don't know. Seeing the userspace counterpart and tests will help in assessing the suggested changes. Regards, Joonas I prepared an IGT test for that, I will send it to a proper mailing list soon. -Tomasz ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v1] Data port coherency control for UMDs.
+ Dave, as FYI Quoting Tomasz Lis (2018-03-19 14:37:34) > The OpenCL driver develpers requested a functionality to control cache > coherency at data port level. Keeping the coherency at that level is disabled > by default due to its performance costs. OpenCL driver is planning to > enable it for a small subset of submissions, when such functionality is > required. Can you please link to the corresponding OpenCL driver changes? I'm assuming this relates to the new-driver-to-be-adopted, instead of Beignet? How is the story/schedule looking for adopting the new driver to distros? Seeing the userspace counterpart and tests will help in assessing the suggested changes. Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
