Am Sun, 05 Oct 2014 10:17:46 +0200 Vincent Danjean <[email protected]> schrieb:
> On 05/10/2014 09:42, Pekka Jääskeläinen wrote: > > On 10/04/2014 08:52 PM, O. Hartmann wrote: > >> ^ ; /usr/local/include/ocl_icd.h:930:11: error: unknown type name > >> 'cl_pipe_properties'; did you mean 'cl_context_properties'? const > >> cl_pipe_properties > >> * /* properties */, ^~~~~~~~~~~~~~~~~~ cl_context_properties > > > > This is an ocl_icd.h issue. It refers to OpenCL 2.0 types while you probably > > have 1.1 or 1.2 cl.h. > > Indeed, ocl-icd added support for OpenCL 2.0 since the 2.2.0 release. > > At build time, if 2.0 OpenCL headers are not present on the system, > ocl-icd uses a included local version. Binary built (libOpenCL.so.1) > must be compatible with ICD 1.1, 1.2 and 2.0 and with applications > using OpenCL 1.1, 1.2 or 2.0. At build time, OpenCL headers ARE present on the system, as installed via port devel/opencl, which resembles from the original OpenCL 2.0 headers provided from Khronos. > > However, for now, the ocl_icd.h generated file, that should be used > to build an ICD, included all prototypes for OpenCL 2.0 ICD (that is > a superset of 1.2 and 1.1). It is something we do not think about when > doing this release. > > It is possible for us to add some gards, so that ocl_icd.h can be used > to build ICD 1.1 or 1.2 without 2.0 support. What would you find the > most useful? I can see two possibilities (you can propose other): > - by default, support ICD 1.1 and 1.2 > you must then add -DOCL_ICD_SUPPORT_2_0 to add 2.0 ICD support > - by default, support the latest ICD version > you must then add -DOCL_ICD_DISABLE_2_0 to hide 2.0 ICD entries I'm not so familiar with the mainstream development, but considering the dramatic speed of OpenCL development and support of OpenCL 2.0 by hardware (Intel Broadwell's iGPU is supposed to be OpenCL 2.0 compliant) my personal vote would be the last option. I understand the terms of OpenCL 2.0 that way, that it is backward compatible. So, if this is naive thinking, my apologizes for the noise. > > As you know which version is supported by your ICD, I think it is > probably better to use my first proposal. But I'm open to any arguments. > Once the behavior is decided, I will quickly do a 2.2.2 ocl-icd release with > this feature. > > Regards, > Vincent > > PS: in fact, perhaps entries must simply by garded by CL_VERSION_X_Y > macro, so that ocl_icd.h adapt itself to OpenCL headers used at build time. I guess, my port devel/ocl-icd (still proposed to FreeBSD) is picking up the wrong headers then, since the OpenCL 2.0 headers from Khronos are installed by default. Maybe there is a missing include. Or, I have not checked this, POCL is not picking up the system installed headers and using its own provided headers? Is there an easy way to check that via log? > > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > pocl-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/pocl-devel
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
