Added Vincent Danjean (co-author of free OpenCL ICD loader) to CC. Dnia 2012-08-21, wto o godzinie 11:25 -0400, Andreas Kloeckner pisze: > Andreas Kloeckner <[email protected]> writes: > > Tomasz Rybak <[email protected]> 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 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. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak
signature.asc
Description: This is a digitally signed message part
_______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
