Closed normanius closed 6 years ago
Some further details about the problem. First, I am working with FAST revision 7ae4987. I am currently using Qt 5.7.0 - as a next step I will check if the problem still occurs for newer versions of Qt.
OpenGL 3.3 is fully supported on my system, according to OpenGL Extensions Viewer app: All tests up to OpenGL 4.1 pass successfully.
Further, I found that the problem occurs in View::initializeGL()
(line 353), when trying to generate the framebuffer:
fun->glGenFramebuffers(1,&fbo);
Thanks for the issue report. The system should build and download automatically Qt 5.8 not 5.7. Have you tried FAST version 1.2 release for mac? https://github.com/smistad/FAST/releases/tag/v1.2.0
Does any of the other executables work, or do you get the same error?
Alright, this was not clear. I was working on master branch. Maybe add this to the instructions. The segfault described above, as well as the other issue #93 I reported were not present with v1.2.0. Good job :)
The viewer app starts (although I was not able to see anything) properly.
However, now testFAST fails with the errors below, and the airwaySegmentation and lungSegmentation examples crash for the same reasons. Shall I create another issue or do you immediately see what the problem is? I downloaded the test data.
...
INFO: Max position found at 255 179 688 with G: 5.54136e-14
INFO: Max position found at 254 180 687 with G: 5.53974e-14
INFO: Max position found at 255 180 688 with G: 5.53902e-14
INFO: Max position found at 254 181 687 with G: 5.53749e-14
INFO: Max position found at 255 181 687 with G: 5.53277e-14
INFO: Max position found at 255 176 687 with G: 4.32711e-14
INFO: Max position found at 255 177 687 with G: 1.22134e-14
INFO: Max position found at -1 0 0 with G: 0
INFO: QApp already exists..
ERROR: OpenCL exception caught in Qt event handler clEnqueueNDRangeKernel(Memory object allocation failure)
ERROR: FAST exception caught in Qt event handler Could not find output data for port 0 in SurfaceExtraction
INFO: Trying to start computation thread
INFO: Computation thread started
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
testFAST is a Catch v1.5.9 host application.
Run with -? for options
-------------------------------------------------------------------------------
Airway segmentation
-------------------------------------------------------------------------------
../source/FAST/Algorithms/AirwaySegmentation/airwaySegmentationTests.cpp:49
...............................................................................
../source/FAST/Algorithms/AirwaySegmentation/airwaySegmentationTests.cpp:49: FAILED:
due to a fatal error condition:
SIGSEGV - Segmentation violation signal
===============================================================================
test cases: 1 | 1 failed
assertions: 1 | 1 failed
The applications airwaySegmentation and lungSegmentation run the airway segmentation algorithm, and testFAST has a test for the airway segmentation algorithm. This algorithm uses a lot of memory.
ERROR: OpenCL exception caught in Qt event handler clEnqueueNDRangeKernel(Memory object allocation failure)
This basically means that your device has run out of memory. It is not so easy to know how much memory is available and used on the GPU, therefore it is hard to make mechanisms that detect and report these errors instead of simply crashing.
True, it seems to be a memory issue. Images of size 512x512x831x16bit (~415MB) seem to be working fine, while I get the segfaults for volume images with dimension 1024x1024x1024x16bit (=2048MB).
This behaviour is consistent with the specs of my system: I work with a Mac Book Pro (Retina, 15-inch, Mid 2015) with Intel Iris Pro and 1386MB of VRAM.
So then I simply turn to my own project and make sure that the input images remain within certain limits. Many thanks for your feedback.
Before your reply, I already did a few more tests because I suspected Apple's limited support for OpenCL for some of the issues. For the sake of reference, I'd like to share the following resources with people that may suffer from compatibility issues:
To test OpenCL capabilities:
Keep in mind that it is possible that the Apple's drivers are not fully compliant with OpenCL standards, although the situation might have been improved over time:
@smistad A note about system requirements in the docs might be helpful. Also, testFAST should maybe execute simpler tests, not that users get the impression that FAST does not work in general. Also, it'd be great if the executable was a bit more tolerant to such kind of failures (warning messages instead of hard crashes). Just making suggestions, I'm good for now... :)
@normanius Good ideas, I will keep it in mind for the next version.
For instance, when executing the viewer, I get the following message on the console:
The crash report looks the following. Any ideas? All apps seem to crash for fast::View::initializeGL()