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 <lists(a)informa.tiker.net> writes:
> Tomasz Rybak <tomasz.rybak(a)post.pl> 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
>> 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
> 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?
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)?
Tomasz Rybak GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860