Le 21/08/2012 22:49, Tomasz Rybak a écrit : > Added Vincent Danjean (co-author of free OpenCL ICD loader) to CC. Adding Brice, the other OpenCL ICD Loader co-author > Dnia 2012-08-21, wto o godzinie 11:25 -0400, Andreas Kloeckner pisze: >> Andreas Kloeckner <lists(a)informa.tiker.net&gt; writes: >>> Tomasz Rybak <tomasz.rybak(a)post.pl&gt; writes: >>>> As I wrote in my email from 2012-08-14, I experienced >>>> crashes in image-related functions in test_wrapper.py >>>> on NVIDIA hardware. I managed to find the reason of that >>>> crash and fix it (patch in attachment). Below you can find >>>> explanation. >>>> >>>> Unlike all other vendors, NVIDIA still have not released >>>> OpenCL 1.2. Image creation functions have changed in >>>> OpenCL 1.2 - now clCreateImage expects to get cl_image_desc >>>> instead of bunch of arguments like height, width, etc. >>>> PyOpenCL tests in Image constructor (pyopencl/__init__.py, >>>> line 200-ish) whether it is run on OpenCL 1.2 or 1.1, >>>> and runs appropriate code based on this. It uses >>>> get_cl_header_version() for this check which fails in >>>> some situations, e.g. on Debian. In Debian we have opencl-headers >>>> (currently in 1.2), ICD loader (1.2) and ICD implementations >>>> with different versions. This means that headers will always >>>> have version 1.2 (or higher - but it'll be the highest >>>> possible version) but platforms might have lower versions. >>>> This was the case of this segfault. PyOpenCL expected to have >>>> new clImageCreate, ICD loader was ready to give pointer >>>> to this function to PyOpenCL, but platform (NVIDIA) >>>> was not providing it. >>>> >>>> I have changed Image constructor to base usage of clCreateImage on >>>> devices' platform version. I assumed that Context always have >>>> at least one device - if not, please change this code. >>> >>> I'm wondering--isn't this an issue with the ICD loader? I had sort of >>> expected that the header needs to match the loader, and if the loader >>> exports a 1.2 interface, then all of those functions are at least safe >>> to call--i.e. I as a user don't have to go around checking versions just >>> to determine what API I can call. >>> >>> In this particular instance, I had thought the ICD loader would >>> translate the call to the old 1.1 interface, or, if impossible, provide >>> an error. >>> >>> A segfault is most definitely not an appropriate response... >>> >>> OTOH, it seems both the AMD ICD loader and the open-source ICD loader >>> (as you indicate) behave this way, so we might not get a choice in this >>> matter. >>> >>> Does the spec say anything on this? What's your assessment? Are these >>> transient bugs in the ICD loader, design flaws in the spec, or something >>> completely different? 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. 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 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. 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. Regards, Vincent >>> I must admit I'm pretty reluctant to call a bunch of GetInfo functions >>> and then do a bunch of string processing just to figure out what >>> function is safe to call. Maybe as a temporary workaround, but not as a >>> permanent thing. >>> >>> Any opinions/insights? >> >> Hi Tomasz, >> >> any news on this front? > > Sorry - did not have time to investigate it deeply. > Description of OpenCL ICD extension does not deal with case > of different platform versions. > > Vincent - any thoughts about how OpenCL should behave > in current case, when loader has version 1.2 and > tries to use ICD with version 1.1 (here NVIDIA one)? > > Best regards. >