is there any downside in compiling with
OpenCL 2.0 support,
Yes - on older (Ivybridge/Haswell - no emitUntypedReadA64Instruction)
hardware, a 2.0-enabled beignet won't work, at all.
I see two possible approaches:
-Build two beignet packages, with and without 2.0 enabled, and make the
with-2.0 one only accept 2.0-capable hardware (cl_get_gt_device() in
src/cl_device_id.c).
They can be coinstallable if they use different BEIGNET_INSTALL_DIR and
ICD_FILE_NAME (I suggest choosing names that make the non-2.0 one sort
first, so software that doesn't need 2.0 doesn't get the performance
penalty of supporting it), but should be separate packages because some
OpenCL-using software errors out if any installed platform has 0 devices
(CL_DEVICE_NOT_FOUND - e.g.
http://sources.debian.net/src/asl/0.1.7-2/src/acl/aclHardware.cxx/?hl=69#L69
,
http://sources.debian.net/src/woo/1.0%2Bdfsg1-1/core/Scene.cpp/?hl=219#L207
)
-As suggested above, move the "does this hardware support 2.0?" check to
run time.
I'm currently working on this: it looks doable, but is the riskier option.
I at least need to decide quickly, as Debian freezes this week.
Two other issues I've found:
-CMake/FindLLVM.cmake doesn't find LLVM 3.9, even though this version is
_required_ for OpenCL 2.0.
-The release notes say cl_khr_gl_sharing is now supported, but
docs/Beignet.mdwn still says it isn't.
_______________________________________________
Beignet mailing list
Beignet@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/beignet
