[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 _______________________________________________ Beignet mailing list Beignet@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/beignet