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:[email protected]] > Sent: Wednesday, March 21, 2018 11:03 AM > To: Dunajski, Bartosz <[email protected]>; Lis, Tomasz > <[email protected]>; [email protected]; Dave Airlie > <[email protected]>; Ewins, Jon <[email protected]> > Cc: [email protected]; Winiarski, Michal <[email protected]> > 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:[email protected]] > > Sent: Monday, March 19, 2018 2:54 PM > > To: Lis, Tomasz <[email protected]>; > > [email protected]; Dave Airlie <[email protected]> > > Cc: Dunajski, Bartosz <[email protected]>; > > [email protected]; Winiarski, Michal > > <[email protected]> > > 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 [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
