I have written some multithreaded code using PyOpenCL, which works fine under the following conditions:

  • GPU 32-bit floating point values (Intel Iris GPU can only handle single precision values)
  • CPU 32-bit floating point values.

All data buffers are defined, and the program executed and output data enqueued, all inside a function which is called within a loop. When using 64-bit double-precision values, the loop runs twice before throwing the error 'Segmentation Fault: 11'.

Therefore, I don't believe it is due to the string-manipulations involved in preparing the OpenCL kernel; more likely seems to be something to do with allocated memory.

Interestingly, the CPU max_work_group is 1024, and GPU max_work_group is 512.

What possible causes could there be for the success using single-precision values, but failure when using double-precision values?

  • 1
    $\begingroup$ You might have better luck on stackoverflow.com. Warning: They are way meaner than us; you might want to give more info than you did here. $\endgroup$
    – user14717
    Feb 26 '18 at 22:50
  • 1
    $\begingroup$ There is not enough information here to diagnose anything. Failing with a segfault is a rather common mode of failure (typically due to an out-of-bounds memory access), so nothing specific can be said based on what you've said in the question. $\endgroup$
    – Kirill
    Feb 27 '18 at 0:13

It's impossible to tell without knowing the code you are using. But fortunately, segmentation faults are easy to debug: basically, a segfault means that you are accessing memory you should not access, and the operating system stops your program at the point where this is happening. This means, that if you run your program under a debugger, then you will see exactly which line is causing the problem -- you can inspect the line where it happened, the local variables and their values at this point, and the backtrace (i.e., which function called the one where the problem happened, which function called that function, etc).

So, run your program in a debugger and see what concretely happened. Everything else is essentially just speculation that may or may not be correct.

  • $\begingroup$ Thanks - I don't know how to debug the OpenCL kernel running within a Python script. Are you able to suggest a way to see what is going on inside the kernel? $\endgroup$
    – Zac
    Feb 26 '18 at 21:30
  • $\begingroup$ I know neither OpenCL nor Python, but debugging is such a universal operation that there must be ways to do this. If all fails, debug by inserting printf statements to see where your program is before it crashes. $\endgroup$ Feb 27 '18 at 4:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.