[Intel-gfx] [RFC v1] Data port coherency control for UMDs.

[Joonas Lahtinen]

+ 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 at linux.intel.com] 
> Sent: Monday, March 19, 2018 2:54 PM
> To: Lis, Tomasz <tomasz.lis at intel.com>; intel-gfx at lists.freedesktop.org; Dave Airlie <airlied at redhat.com>
> Cc: Dunajski, Bartosz <bartosz.dunajski at intel.com>; chris at chris-wilson.co.uk; Winiarski, Michal <michal.winiarski at intel.com>
> 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