A potential problem with Microsoft OpenCL™ and OpenGL® Compatibility Pack on...
OpenCL support for GNU Octave
Brought to you by:
mattwklein
Menu
▾
▴
Hi Matt,
I have submit an issue to Microsoft https://github.com/microsoft/OpenCLOn12/issues/30 regarding a problem that produce wrong results for ocl_cat functions. Could you please have a look at it? I guess it is their runtime problem, and ocl_tests will fail when using it. I also created a wiki page to talk about the runtime, this runtime can be installed from MS store directly. https://sourceforge.net/u/tangjinchuan/wiki/I%20heard%20that%20Microsoft%20has%20an%20OpenCL%20implementation%20called%20OpenCL%E2%84%A2%20and%20OpenGL%C2%AE%20Compatibility%20Pack%2C%20should%20I%20use%20it%20%3F/
Best wishes,
Jinchuan
This one is quite interesting. I now have some clues after testings with different assumptions on ocl_cat.
One important thing I discovered was that If a kernel have been enqueued twice or more (e.g., for loop in cat kernel submission), and if none of it is being executed at the device side, then this OpenCLOn12 runtime will ignore the previously queued kernel cmd but only leave the latest one who has the same kernel name. This causes the incorrect results while doing examples like ocl_cat(1,a,a,a).
The magic happens when I add clBarrier, clFlush, clFinish one after another to each enqueue inside the for loop, the results now are correct. It's 12:36AM already at my place. I guess I will have a further look at to see if this is the important case or some functions out of thoese three are good enough.
So, basically, adding clFlush only to a for loop based same-kernel-name submission will work for OpenCLOn12 at a cost of speed for ocl_cat and ndgrid or their related functions.
Meanwhile, OpenCLOn12 runtime will give incorrect results for single input+ single output version of max, min, accmax and acumin. It is quite similar to AMD's runtime which has a problem when comparing a pointer with another, which was used in four kernels to check if the index outputs is available or not. Since Matt has mentioned there would be problem if simply send 0/NULL as a kernel argument in some old runtimes, the solution here is let what is similar to "give to Caesar what belongs to Caesar, and give to God what belongs to God.". Simply use a kernels with index input and another one without.
As a result, the system now can run on OpenCLOn12. This is a great news to some Windows-ARM based system that does not have native OpenCL runtime at the moment but supports Dx12 Interfaces.
The problem is solved.
Happy Christmas!
I have upload a test case to preproduce MS’ runtime problem and upload it to their GitHub. So let’s wait and see their response. As a result I won’t push to release a patch for this runtime with clfinish for this will definitely disable the batch submission for ocl_cat.
After a long time, MS finally confirmed this as a good bug and claimed to fix this problem.