IPP causes invalid opcode exception at h9_ippsFFTGetSize_C_32fc

[BFalk]

We are using IPP version 7.1.1.119 on 4th generation (Haswell) Core i7 processor under INtime (5) operating system. Our code runs in 32-bit mode (INtime currently does not support 64-bit mode).

We are using static linkage (#include <ipp_h9.h> before #include <ipp.h>).

A call to ippsFFTInitAlloc_C_32fc causes an invalid opcode exception. This occurs inside h9_ippsFFTGetSize_C_32fc function when trying to execute what looks lik "les esp,edx" instruction. I now know that this is a VEX prefix instruction.

Note: When configuring IPP for AVX rather than AVX2 (using ipp_g9.h instead of ipp_h9.h) - everything works correctly. It so happens that  g9_ippsFFTGetSize_C_32fc does not comprise that VEX instruction.

We verified that our processor supports AVX2 (ran the piece of code suggested by Intel for checking this).

 Notwithstanding the statement at http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions saying that VEX instructions are not available in 32-bit mode, it seems that VEX instructions can be run in 32-bit mode (e.g. see http://software.intel.com/en-us/forums/topic/394196). If that is the case, this could be a bug (feature?) in IPP.

Please avise.

Thanks,

Beni Falk

[SergeyKostrov]

>>...We are using IPP version 7.1.1.119 on 4th generation (Haswell) Core i7 processor under INtime (5) operating system... Is there any chance to get a complete list of loaded IPP modules ( including IPP Waterfall )? On Windows platforms it is a very simple procedure and I don't know how to do it on INtime (5) operating system. >>If that is the case, this could be a bug (feature?) in IPP... I wouldn't call it as a "feature" if it crashes your application.

[BFalk]

Sergey,

We are using static linkage:

a) Adding the following to the compiler include file path (in this order):

C:\Program Files\Intel\Composer XE 2013\ipp\lib\ia32

C:\Program Files\Intel\Composer XE 2013\ipp\tools\ia32\staticlib

b) #include'ing <ipp_h9.h> before #include'ing <ipp.h>

c) Linking with ipps_l.lib, ippvm_l.lib, ippcore_l.lib

Note: We are using Microsoft Visual Studio 2008 SP1.

Hope this answers your question.

Thanks,

Beni

 P. S.

Please take a look at http://software.intel.com/en-us/comment/1741584#comment-1741584 . People there have decoded the instruction that caused the invalid operation exception and put me on a different track - it turns out that this is a BMI2 instruction (SHLX) rather than an AVX2 instruction. I will now verify that the processor I am using (a Haswell) indeed reports supporting BMI2.

[BFalk]

It turns out that the CPU that we are using (purportedly Core i7-4700EQ - it is comprised within an Advantech SOM-5894 COM-Express module; it is identified as type 0000 by the BIOS and Windows) does not support BMI2 (nor BMI1, for that matter). We have verified this by using CPUID.

I have the following questions:

a) Does IPP when used in AVX2 mode (#include <ipp_h9.h> before #include <ipp.h>) mandate support of BMI(2) instruction set extensions?

b) Are there any 4th generation (a.k.a.) Haswell Core-i7 chips which do support BMI2?

c) Assuming there are any, is it possible to run IPP in AVX2 mode in 32-bit mode?

Thanks,

Beni

[SergeyKostrov]

>>...c) Assuming there are any, is it possible to run IPP in AVX2 mode in 32-bit mode? Yes and this is what Intel® Integrated Performance Primitives for Windows* OS User's Guide ( 318254-016US ) says on page 19: ... IA-32 Intel® architecture ... h9 - Optimized for processors with Intel® Advanced Vector Extensions (Intel® AVX2) ...

[BFalk]

Sergey,

Do you know whether IPP 7.1 has been tested in AVX2 mode (h9) on any Haswell processor? If yes - on which?

I am specifically interested in using FFT functions (as I wrote, the crash occurred inside h9_ippsFFTGetSize_C_32fc).

[SergeyKostrov]

>>...Do you know whether IPP 7.1 has been tested in AVX2 mode (h9) on any Haswell processor?.. Let me answer as follows: I do believe that it was tested and that is why there is a note about h9 in IPP User's Guide ( 318254-016US ). I don't believe that it wasn't tested. By the way, there is a thread with a similar problem and another user of IPP library has almost the same problem with ippsZero_32f function ( IPP version 7.0.205 / 64-bit environment / e9 code for Waterfall DLL ). Here is a test case I've implemented: // Verification for DSP domain DLL ( AVX / e9 ) is needed /* List of IPP DLLs used: 24/09/2012 11:25 PM 144,864 ippcore-7.1.dll 24/09/2012 11:25 PM 240,608 ipps-7.1.dll 25/09/2012 01:21 AM 5,499,360 ippse9-7.1.dll */ #include "stdio.h" #include "ipps.h" int main( void ) { Ipp32f fData[ 256 ]; printf( "Test Started\n" ); IppStatus st = ::ippsZero_32f( &fData[0], 256 ); printf( "Test Completed\n" ); return ( int )1; } /* [ Output ] Test Started Test Completed */ Take a look if you have a couple minutes to test it. The user I'm talking about has Not-Fully updated Windows 7 OS and I don't know why it wasn't updated. On my Ivy Bridge system Windows 7 Professional is regularly updated and I didn't detect any problems with the test case. I see some similarities between these two threads ( two problems ) and I suspect that in both cases operating systems do not support AVX or AVX2 completely. However, this is only my guess and it is Not proven.

[SergeyKostrov]

>>...A call to ippsFFTInitAlloc_C_32fc causes an invalid opcode exception. This occurs inside h9_ippsFFTGetSize_C_32fc >>function... I'd like to note that both functions: ippsFFTInitAlloc_C_32fc and ippsFFTGetSize_C_32fc are Not in the list of IPP functions optimized to benefit from Haswell's new instructions. Take a look at: http://software.intel.com/en-us/articles/haswell-support-in-intel-ipp

[Sergey_K_Intel]

Hi Beni,

There are pre-built performance tests in <installation dir>/ipp/tools/ia32/perfsys directory. You can check FFT functionality on Haswell/32-bit, if run, for example,

  ...ipp\tools\ia32\perfsys\ps_ippi -fFFT -B

on Haswell CPU. You'll see IPP library name (h9 or not?) and function execution statuses. Provide us with console output text, let's look on results.

Refards,
Sergey 

[BFalk]

Sergey,

My problem is that I have to use IPP with static linkage since the operating system that I am using (INtime) does not support Win32 DLLs (at least not to my knowledge). Thus, even if I wanted to, I cannot mix and match routines from several libraries (e.g. g9 and h9) - if I want to use h9 for some IPP functions then I must use it for all.

As I wrote, when using g9 everything worked correctly. Again, this seems not to be a problem of AVX2 but of BMI(2) (the faulting instruction belongs to the BMI2 set).

INtime tech support indicated that they shouldn't have any problems with AVX2 (they properly save and restore the associated registers on a context switch, etc.). Thus I believe that it boils down to BMI2 instruction set support by the CPU.

The document that you referred me to (http://software.intel.com/en-us/articles/haswell-support-in-intel-ipp) does seem to indicate that Haswell chips should support the BMI instructions, however the datasheets page for the chip that I am using (http://ark.intel.com/products/75469/Intel-Core-i7-4700EQ-Processor-6M-Cache-up-to-3_40-GHz) does not mention it. I have seen hints on other forums indicating that some Haswell chips support these operations and some don't.

The fact is that the IPP function that I tried to use (ippsFFTGetSize_C_32fc), when using IPP in h9 mode, uses such an instruction and I cannot do anything about that (if I want to take advantage of AVX2 enhancements then I must use IPP in h9 mode). This is the reason why I asked whether IPP in h9 mode was tested on any Haswell processor and if yes - on which.

Thanks,

Beni