[Beignet] [PATCH v2] Enable OpenCL 2.0 only where supported

Rebecca N. Palmer rebecca_palmer at zoho.com
Tue Jan 24 20:53:34 UTC 2017


[New recipients: this is a reply to
https://lists.freedesktop.org/archives/beignet/2017-January/008516.html ]

On 24/01/17 08:58, Pan, Xiuli wrote:
> And we have a conformance test with these patches, and the only problem is that the sizeof(void *):
> On GEN9 machine, the device will return 32 due the CL1.2 backend is using but the host API query one returns 64, 
> and if -cl-std=2.0 is using the sizeof will be 64. The API could only return one value but our backend now have two kinds.

The spec for clGetDeviceInfo
(https://www.khronos.org/registry/OpenCL/specs/opencl-2.0.pdf page 64)
says CL_DEVICE_ADDRESS_BITS is the *default* address space size,
i.e. 32 here.

As the only place device->address_bits (from
src/cl_get_gt_device.h:45) is used is as the return value of that
clGetDeviceInfo call, making it unconditionally 32 should be enough
to implement this.

I'm guessing this isn't a big problem in practice (and hence, currently
do *not* intend to change the Debian package for this release),
but would welcome other opinions.

A quick check of
codesearch.debian.net suggests only 2 of their ~70 OpenCL-using
packages use it for something other than just "print device info",
and neither of them looks like this would add a new problem:
- clblas, probably only in the AMD-hardware-specific parts
- gromacs, in a way that looks like a bug anyway, since they appear
to mean CL_DEVICE_MAX_WORK_ITEM_SIZES but never check that -
http://sources.debian.net/src/gromacs/2016.1-2/src/gromacs/mdlib/nbnxn_ocl/nbnxn_ocl.cpp/?hl=524#L524



More information about the Beignet mailing list