RealsenseViewer crashes with "Illegal instruction" on Xeon E5-2643

[MSoegtropIMC]

librealsense	2.44.0 RELEASE
OS	Windows 10

When I install and start RealsenseViewer 2.44, it immediately crashes with an "Illegal CPU instruction" on a Xeon E5-2643.

My opionion on this is:

• basic explortion tools like this should also work on older lab workstations
• quality software should detect the CPU achitecture and fallback to software compatible to older CPUs - I would think Intel has good performance libraries which do this automatically
• Intel SW should be compatible to reasonable Intel HW
• If this is not possible for whatever reason, the box and online description of the camera should mention minimum system requirements

Note: the Depth Quality Tool works fine.

[MartyG-RealSense]

Hi @MSoegtropIMC The version of the RealSense Viewer that is bundled with the RealSense SDK installation has a requirement of a 6th Generation Intel Core processor or newer because of its OpenVINO functions. Your E5-2643 is a 2nd generation processor.

You can though download a standalone version of the RealSense Viewer named Intel.RealSense.Viewer.exe from the Assets file list on the SDK Releases page that does not have this requirement because it does not contain the OpenVINO functionality and so will work with older processors. The rest of the SDK should also work fine on an old processor, as the processor requirement is only on the bundled Viewer program and the 400 Series cameras can work with any Intel or Arm processor.

https://github.com/IntelRealSense/librealsense/releases/tag/v2.45.0

Once the standalone Viewer is downloaded, you should double-leftclick on Intel.RealSense.Viewer.exe in the folder that you downloaded it to to launch the Viewer. Do not use the launch shortcut on the Windows desktop, as that links to the bundled Viewer version with the processor requirement.

If you need a launch shortcut, you can delete the desktop Viewer shortcut and create a new shortcut to the standalone Viewer's .exe file by right-clicking on the file and selecting the Create shortcut menu option.

[MSoegtropIMC]

@MartyG-RealSense : thanks, I can conform that this works.

I still find it questionable that the first thing a user sees is a crash. It shouldn't be that complicated to make OpenVino such that it reports that it can't be used rather than crashes in its init function, so that RealSenseViewer would still work except for OpenVino functionality. Since OpenVino is also from Intel, it should be possible to get that sorted out.

[MartyG-RealSense]

My understanding is that OpenVINO depends on a processor supporting the AVX instruction set, which old processors may not have, and that is why the Viewer that includes OpenVINO fails on pre-6th generation processors.

#7080 (comment)

[MSoegtropIMC]

Every Intel CPU has for every feature which was not in the first Pentium flags to query at run time if the feature is available or not. Software should check these flags before it uses any of these features and at least output a sensible error message rather than just crash. IMHO software which crashes with an illegal instruction is acceptable for a student project, but not for commercial software.

See e.g. (https://software.intel.com/content/www/us/en/develop/articles/how-to-detect-new-instruction-support-in-the-4th-generation-intel-core-processor-family.html)

Regarding OpenVino: as far as I understand this, OpenVino is only required for advanced features in RealsenseViewer. So the proper way to go is that the DLL init function of OpenVino checks if whatever CPU features it requires are actually available. If not it should return false from init or a later status query function to signify that it cannot be used. Realsenseviewer could then still provide all the functionality the extra download version you pointed me to has.

[MartyG-RealSense]

Thanks very much for the detailed feedback. I will tag RealSense team member @ev-mp to highlight your development suggestions to them.

[MartyG-RealSense]

Hi @MSoegtropIMC Do you require further assistance with this case, please? Thanks!

[MartyG-RealSense]

Case closed due to no further comments received.

[MSoegtropIMC]

As I already said, using the the separately downloadable app works, but I still think that this work around wouldn't be required if the use of advanced CPU features would have been done following the procedures Intel suggests. So it is fine to close this, but I would expect it to be linked to a follow up issue which addresses the real issue.

[MartyG-RealSense]

I have previously tag-highlighted your comments to RealSense team member @ev-mp but will highlight them to Intel through a different contact channel.

[MartyG-RealSense]

Hi @MSoegtropIMC After discussion with Intel, I have filed an official bug report with Intel regarding this issue of the Illegal CPU instruction! Possibly newer CPU architecture is required error. This case should be kept open whilst the bug report is active. There is nothing further that you need to do. Thanks for the report!

[MSoegtropIMC]

This case should be kept open whilst the bug report is active.

@MartyG-RealSense : thank you - I believe this is the right way to go.

[MartyG-RealSense]

Hi @MSoegtropIMC Related to the subject of processor compatibility checks, RealSense SDK 2.47.0 has been released and includes a CMake build flag to disable AVX support for OpenVINO.

[MartyG-RealSense]

Hi @MSoegtropIMC Given the above comment about handling for CPU compatibility having been addressed in SDK 2.47.0, is it okay to close this case? Thanks!

[MSoegtropIMC]

I still believe that quality software should automatically detect the CPU architecture and provide a fallback solution. Especially in this case, where the use of OpenVino is optional. The RealSense code you just delay loading of the OpenVino DLL until it is really used, or just record the error message and then throw an error in case one wants to use OpenVino. A perfect solution would be to provide an highly optimized and a fallback version of OpenVino (using the CMake switch you mentioned) with the RealSence tools, check the CPU architecture and load one or the other.

So my conclusion is that there exist workarounds, but that this is not satisfactory solved.

[MartyG-RealSense]

I do not foresee that there is going to be another approach to this issue developed in addition to the one that was already implemented in 2.47.0.

[MartyG-RealSense]

Case closed due to solution implemented, as mentioned above in #8983 (comment)