+ 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
