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
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?
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:
>
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
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
+ 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:
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:
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.
+ 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
