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.lahtinen@xxxxxxxxxxxxxxx] > Sent: Wednesday, March 21, 2018 11:03 AM > To: Dunajski, Bartosz <bartosz.dunajski@xxxxxxxxx>; Lis, Tomasz <tomasz.lis@xxxxxxxxx>; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Dave Airlie <airlied@xxxxxxxxxx>; Ewins, Jon <jon.ewins@xxxxxxxxx> > Cc: chris@xxxxxxxxxxxxxxxxxx; Winiarski, Michal <michal.winiarski@xxxxxxxxx> > 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.lahtinen@xxxxxxxxxxxxxxx] > > Sent: Monday, March 19, 2018 2:54 PM > > To: Lis, Tomasz <tomasz.lis@xxxxxxxxx>; > > intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Dave Airlie <airlied@xxxxxxxxxx> > > Cc: Dunajski, Bartosz <bartosz.dunajski@xxxxxxxxx>; > > chris@xxxxxxxxxxxxxxxxxx; Winiarski, Michal > > <michal.winiarski@xxxxxxxxx> > > 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
