underlying C OPENCL version not matching the latest version of PyOpenCL wrapper

[KingofSnow01]

I have been using PyOpenCL for some time and find it to be a solid and convenient OpenCL wrapper to use on the Host side with Python.

But lately, when I tried to employ the OpenCL SVM mechanism, for the purpose of making the code more efficient, I could not bring it to a properly working state, although it should have been a relatively simple procedure, and I tried it through multiple options.

While debugging I see it might be the case that although I am using the latest PyOpenCL version, the corresponding C OpenCL version being called by the wrapper is not the latest one.
Firstly, the C OpenCL often “complains” that it does recognize some methods and/or parameters, wherein AFAIK it should have recognized those at least in the latest versions of OpenCL.

Moreover, when I look at the “device” variable under the debugger the <opencl_c_version> attribute shows 'OpenCL C 1.2 ', while the device is fairly new, and it shows OpenCL 3.0 CUDA for its device side version. Under the attribute <opencl_c_all_version> I see a list of 4 different version numbers, where <numeric_version > depicts the lowest of these numbers which is 12582912.

Can it be indeed the case, that an older C OPENCL version was attached to PyOpenCL wrapper? if so, how can I change this setting to a new C OPENCL version?
Any help in this subject would be very much appreciated!

[inducer]

There are a number of variables here, unfortunately:

• What version of OpenCL is supported by your device/ICD? (That's device.version.)
• What version of OpenCL is supported by your ICD loader (i.e. libOpenCL.so)? (I'm not sure there's a great way to find out. As a proxy, you could mention how that file was installed. Use ldd on the PyOpenCL C extension to find out what is being used.)
• What version of the OpenCL headers was PyOpenCL built against? (That's pyopencl.get_cl_header_version.)

Ultimately, the OpenCL API supported will be determined by the lowest of the three. (Fortunately, all but the first are easy to fix, once identified.)

Also, ideally provide full tracebacks for the errors you see, these often have important contextual clues.

[KingofSnow01]

Many thx for the fast reply :-)

• As for the points you raised above, I should first note that there is 1 device on the platform which is 'NVIDIA GeForce MX450'

           device.version = 'OpenCL 3.0 CUDA' 
  

• As for the version supported by the ICD loader, I have only limited indirect information. Since the code is running on Windows 11, I assume that the loader is OpenCL.dll in the C:\Windows\System32 folder. Using the dependency walker tool, the only relevant information is the list of entry points to the DLL, which I guess, may hint at the supported version for a person proficient in OpenCL. I attach the list of entries at the end of this response.

• The version where OpenCL headers were PyOpenCL built against: (3, 0)

• As for error traces - the previous ones have unfortunately been deleted, but I will try to regenerate some of those in the next couple of days.

I hope this information gives some clue, about the actual OpenCL version being used
Again many thx,

List of Entry points within OpenCL.dll:
clBuildProgram
clCloneKernel
clCompileProgram
clCreateBuffer
clCreateBufferWithProperties
clCreateCommandQueue
clCreateCommandQueueWithProperties
clCreateContext
clCreateContextFromType
clCreateFromGLBuffer
clCreateFromGLRenderbuffer
clCreateFromGLTexture
clCreateFromGLTexture2D
clCreateFromGLTexture3D
clCreateImage
clCreateImage2D
clCreateImage3D
clCreateImageWithProperties
clCreateKernel
clCreateKernelsInProgram
clCreatePipe
clCreateProgramWithBinary
clCreateProgramWithBuiltInKernels
clCreateProgramWithIL
clCreateProgramWithSource
clCreateSampler
clCreateSamplerWithProperties
clCreateSubBuffer
clCreateSubDevices
clCreateUserEvent
clEnqueueAcquireGLObjects
clEnqueueBarrier
clEnqueueBarrierWithWaitList
clEnqueueCopyBuffer
clEnqueueCopyBufferRect
clEnqueueCopyBufferToImage
clEnqueueCopyImage
clEnqueueCopyImageToBuffer
clEnqueueFillBuffer
clEnqueueFillImage
clEnqueueMapBuffer
clEnqueueMapImage
clEnqueueMarker
clEnqueueMarkerWithWaitList
clEnqueueMigrateMemObjects
clEnqueueNativeKernel
clEnqueueNDRangeKernel
clEnqueueReadBuffer
clEnqueueReadBufferRect
clEnqueueReadImage
clEnqueueReleaseGLObjects
clEnqueueSVMFree
clEnqueueSVMMap
clEnqueueSVMMemcpy
clEnqueueSVMMemFill
clEnqueueSVMMigrateMem
clEnqueueSVMUnmap
clEnqueueTask
clEnqueueUnmapMemObject
clEnqueueWaitForEvents
clEnqueueWriteBuffer
clEnqueueWriteBufferRect
clEnqueueWriteImage
clFinish
clFlush
clGetCommandQueueInfo
clGetContextInfo
clGetDeviceAndHostTimer
clGetDeviceIDs
clGetDeviceInfo
clGetEventInfo
clGetEventProfilingInfo
clGetExtensionFunctionAddress
clGetExtensionFunctionAddressForPlatform
clGetGLObjectInfo
clGetGLTextureInfo
clGetHostTimer
clGetImageInfo
clGetKernelArgInfo
clGetKernelInfo
clGetKernelSubGroupInfo
clGetKernelWorkGroupInfo
clGetMemObjectInfo
clGetPipeInfo
clGetPlatformIDs
clGetPlatformInfo
clGetProgramBuildInfo
clGetProgramInfo
clGetSamplerInfo
clGetSupportedImageFormats
clLinkProgram
clReleaseCommandQueue
clReleaseContext
clReleaseDevice
clReleaseEvent
clReleaseKernel
clReleaseMemObject
clReleaseProgram
clReleaseSampler
clRetainCommandQueue
clRetainContext
clRetainDevice
clRetainEvent
clRetainKernel
clRetainMemObject
clRetainProgram
clRetainSampler
clSetCommandQueueProperty
clSetContextDestructorCallback
clSetDefaultDeviceCommandQueue
clSetEventCallback
clSetKernelArg
clSetKernelArgSVMPointer
clSetKernelExecInfo
clSetMemObjectDestructorCallback
clSetProgramReleaseCallback
clSetProgramSpecializationConstant
clSetUserEventStatus
clSVMAlloc
clSVMFree
clUnloadCompiler
clUnloadPlatformCompiler
clWaitForEvents

[inducer]

Some thoughts:

• Looks like the ICD does support SVM (as evidenced by the presence of related entrypoints).
• Which kind of SVM were you trying to use? (coarse-grain buffer, fine-grain, fine-grain system?)

Beyond that, a backtrace and, ideally, a reproducer are needed to help meaningfully.

[KingofSnow01]

Hi again,
Here are 3 different versions of call variations I tried to use, the first two resulted in a run time error, while the third did not result in a run time error, but failed to work in a somewhat peculiar way, which I'll explain below.

1. Code: image_array = cl.svm_empty(ctx, cl.svm_mem_flags.READ_WRITE | cl.mem_flags.SVM_FINE_GRAIN_BUFFER,
   (no_of_frames, height, width), np.uint16)

   Error:: AttributeError: type object 'pyopencl._cl.mem_flags' has no attribute 'SVM_FINE_GRAIN_BUFFER'

   Doc:: SVM_FINE_GRAIN_BUFFER Available with OpenCL 2.0.

2. Code: image_array = cl.fsvm_empty(ctx,(no_of_frames, height, width), np.uint16)
   Error:
   File "\Python\Python39\lib\site-packages\pyopencl_init_.py", line 2361, in fsvm_empty
   return svm_empty(ctx,
   File "\Python\Python39\lib\site-packages\pyopencl_init_.py", line 2299, in svm_empty
   svm_alloc = OverriddenArrayInterfaceSVMAllocation(
   File "\Python\Python39\lib\site-packages\pyopencl_init.py", line 1545, in init
   super().init(ctx, size, alignment, flags, queue)
   pyopencl._cl.RuntimeError: clSVMAlloc failed: OUT_OF_RESOURCES

There shouldn't be any real resource issues in this configuration, and parameter values are well-defined.

3. In the third version, there is no run time error, but the code fails to perform in what seems like a strange "write-only" access to SVM buffer from the Host side ( I set the flag to read-write). I allocate input and output buffers, and set values at the input buffer from Host, wherein the GPU kernel side seems to get this setting properly and write values to the output buffer. However, from the host side, both input and output buffer read [000...00]...[0000].... through printouts or debugger. Here is a shortened version of the code:

    image_array = cl.svm_empty(ctx, cl.svm_mem_flags.READ_WRITE,
                               (no_of_frames, height, width), np.uint16)
    output_image_array = cl.svm_empty(ctx, cl.svm_mem_flags.READ_WRITE,
                               (no_of_frames, height, width), np.uint16)
   
    ....
    # update image_array with data and set some other parameters
    ....
    buf1 = cl.SVM(output_image_array) # tag as SVM buf for sending to kernel
    buf2= cl.SVM(image_array)
   

   event = program.update_kernel(queue, global_size, None,
   buf1,
   buf2,
   param_buf, out_flag_buf)

    event.wait()
   
    ... 
   
    here both image_array and out_image_array seem to contain all zeros from the host side
   

I hope this will help to clarify the situation, and thx again to all responders.
Yair

[inducer]

• Variant 1 is due to the OpenCL headers against which PyOpenCL is compiled being too old to have SVM. (i.e. pre-2.0)
• Variant 2 is an error reported by your ICD. If it's CUDA, try to see if you can use their debugging tools to find out. (Or try to use pocl-cuda.)
• Variant 3 looks like a synchronization issue to me. You'll either need fine-grain SVM or explicitly map the allocation into host address space.

[matthiasdiener]

As a side note, please note that SVM is an optional feature in OpenCL 3.0. The actual support might depend on your driver & device capabilities.