Creating kernel panics on Mac OS X #65
Comments
|
Michael, |
|
Could you please provide the stack trace from the Would you mind also running I have a strong suspicion of the cause but I don't have access to a Mac so I can't be sure. I appreciate your help getting to the bottom of this. |
|
Also, you may as well include the output of the |
|
Sure, here's the backtrace from Note that I commented out everything in main() except the call to Output of Output of Let me know if I can test anything for you! Debugging this without a access to a Mac is probably kinda challenging ;) |
|
I see we also have a secondary error produced by I have what should be a fix to the initial issue up on the master branch. Please clone/pull this repo and try running If it works, we'll have a look at the command queue issue. |
|
|
|
Ok great. Those errors in the info output are just features that your platform doesn't support and is working as intended. I may add an extra check and squelch/condense that error message. As to the secondary issue, the I appreciate your help testing this :) |
|
That's good to hear! :) There is also one test Thank you very much for your work and your super-fast response! :) |
|
f992ab3 should fix issues with queue creation. When you have a chance, please verify that:
cogciprocate/ocl-core@87167ca should make output from the No hurry on any of this. Thanks a lot for your help. |
|
I tried it using Master, here are the results:
I apologize for causing so much trouble ;) |
|
Let me add that none of the above failures are critical for me personally and I know that debugging this is next to impossible for you, so feel free to close this issue as wontfix. The only thing that would be nice to have are the profiling events, I'll check tomorrow with a minimal C example whether they are supported on OSX and if yes, I'll open a new issue here with more details. |
|
No trouble at all. I appreciate all of this useful feedback. I want things to work 100% on all platforms (or at least fail for clear reasons). Some of the hangs and errors related to the new asynchronous features I've added in 0.13 are somewhat expected. I even get them when running on older Intel processors (Sandy Bridge) due to elements of the processor design which aren't totally compatible with OpenCL (and is why OpenCL isn't officially supported on that family). By running the async tests and examples with the I'm confused as to why we're still getting Is I'll respond to the profiling issues in the new thread :) |
|
I think we're finally about to get to the bottom of this :) Tests run fine when using So what's left:
|
|
Ok great. I'm changing the For now, please try out the I'll fix the other example and let's confirm that they're all working / failing properly. Please create another new issue for |
|
The Let me know :) |
|
So I just tested this with current master,
(output varies between runs, sometimes it completes some more tasks, sometimes less). |
|
Ok interesting... I'll make some more tweaks here in the next day or so. |
|
d239b1a: The
That leaves us with and If the CPU device runs it fine but the GPU one deadlocks just like |
|
I just checked this on current master, both the CPU and GPU version of Tests do not compile: After fixing that error (just a comma and semicolon too much) tests run fine with |
|
Ok so if I'm not missing anything only one last issue to go. Let's move the discussion to #73. |
Dear all,
I tried running the "trivial.rs" example on my Mac (OS X 10.11, pre-installed OpenCL 1.2, ocl version 0.13.0) put it panics when creating the kernel because
Kernel::new("add", &program)returnsErr([NONE]). It does this in the versions in main(), main_explained(), and main_exploded(), but interestingly NOT in main_cored() which uses ocl-core...In
main_coredI also added a call tocore::get_kernel_info(&kernel, KernelInfo::NumArgs)immediately after creating the kernel (because that's what the other non-working examples do behind the scenes) but that's working fine.I tested this using both the CPU and GPU devices in the platform, both do not work. Interestingly, when using just the GPU device and printing that one out using
println!("Device: {:?}", device);I get the following suspiciously looking output:Please let me know if you need further information (like the output of
clinfocommand) or if there is anything else I could try!Thank you very much!
Michael
The text was updated successfully, but these errors were encountered: