Hi Vincent, Vincent Danjean <[email protected]> writes: >> I think this is a design flaws in the specs. >> An ICD Loader has no information at all (unless we decide to hardcode >> some of them) about the supported OpenCL functions by the loaded ICD.
The ICD loader *could* call the implementation's platform version GetInfo, though, and route the CreateImage calls accordingly? But if that's not accepted practice among ICD loaders, it's not useful, as PyOpenCL has to work against all of them. Is any of you on the CL committee and able to let them know that they screwed up? If not, I can reach see if I can reach someone... >> An ICD Loader merely get a address of of array of function pointers. It >> even does not know the size of the array it gets. This means, there is >> no reliable way to know if the address we got for a 1.2 function is >> garbage (belong the end of the table of an 1.1 implementation) or >> correct. >> Looking at version advertised by the ICD implementation is not a >> solution: Intel implementation advertises 1.1 but implement (part of) >> 1.2 That seems perfectly within-spec. I.e. "call the 1.2 bits at your own risk". I don't see the ICD loader under any obligation to make it possible to call the 1.2 bits if the ICD advertises 1.1. >> I'm willing to add/patch anything required in ocl-icd. We can add some >> more functions to the interface (it means that a program using these >> functions will not work with other OpenCL ICD loader) or provides >> them in an additional library (so that it works with any ICD Loader >> implementation). >> But, for now, I see no other way than using hardcoded information. >> If we go this path, we should think about which information we want >> exactly and how we want them to be presented (ie API/ABI) >> >> What I can propose is that, for any public symbol, we try to look >> if the corresponding function exists in the targeted ICD. Some >> sanity checks can be done automatically (non-null pointer, ...) >> but some hard-coded information will be required. >> >> I also ask me how/if we can divert the internal function pointer >> structure provided by the implementation in order to fully fill >> a whole structure (with error functions for the missing ones). >> I think that is is feasible. But that it would be possible for >> a strange ICD implementation to respect the standard and break >> with what I imagine (ie my implementation would be border-line >> with respect to the ABI specifications) >> >> >> About the specific problem of clCreateImage, I tried to look at >> it. If I understand correctly, >> OpenCL 1.1 defines clCreateImage2D and clCreateImage3D >> OpenCL 1.2 defines clCreateImage and deprecates clCreateImage2D >> and clCreateImage3D >> I.e, contrary to the initial message, I do not think that a >> prototype changes (this would be a severe bug with respect to >> ICD Loader specifications). But we have 2/3 functions with >> similar prototypes, some provided by some implementations, >> other provided by other implementations. What a nightmare. >> But, for now, I do not think there is any way an implementation >> can currently reliably detect at run-time if an specific plate-form >> implement or not theses functions. (Not sure I agree here--see first comment.) Andreas _______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
