Restrictions on Offloaded Code for Intel® Graphics Technology

This topic only applies to IA-32 architecture targeting Intel® Graphics Technology. Intel® Graphics Technology is a preview feature.

We frequently offer preview features to encourage dialog with our user-community; this gives them an opportunity to tell us what they would like in the more developed or extended capability version. While this is a preview feature, Intel® Graphic Technology is a supported part of the compiler product. The feature is functional as implemented, but additional capabilities inherent or related to the feature are not yet available; the support limitations or restrictions are listed below. Intel may change the current implementation at any time in ways that could significantly change expected behavior. A non-preview version of this feature may or may not appear in future releases.

Offloaded code has the following restrictions:

• You can place #pragma offload target(gfx) only before a perfect loop nest explicitly marked as parallel by #pragma parallel_loop.

• Do not use the __GFX__ macro inside the statement following a #pragma offload statement. You can, however, use this macro in a subprogram called from the pragma.

• This restriction does not apply to Windows* 8 OS and Windows Server* 2012. Offload to the target is only possible from a session which has access to the graphics driver. The practical implication is that

  • Offload is possible:

    • from a local desktop session, when the desktop is not locked and no screen saver is running

    • from a Remote Desktop connection, when the remote desktop client window is open

  • Offload is not possible from Session 0 where all services are run on Windows Vista* OS, Windows* 7 OS, Windows Server* 2008, and later versions.

• By default, the system does not allow for an offload task to execute longer than the system recovery timeout period, which is usually two seconds. In the offload runtime, the task appears to be hanging and abnormally terminating after another timeout, which has a value of 32 seconds. To enable your offload tasks to execute more than 32 seconds, refer to Microsoft's documentation on the Timeout Detection and Recovery (TDR) registry keys to disable recovery on timeout in the system registry.

• To offload to the target on a machine with a discrete graphics card installed, you need to make the target the primary graphics device.

• All macros inside a #pragma offload region must evaluate to code using the same set of variables. For example, the following code leads to undefined behavior, because N, inputArray and outputArray are not used in the CPU version of the code:

  #pragma offload target(gfx) pin(inputArray, outputArray: length(N))
  #pragma parallel_loop
  for (int i = 0; i < N; i++){
  #ifdef   GFX 	
     out[i] = in[i]/N;
  #else
     // nothing
  #endif
  }
  

• The parallel loops associated with #pragma parallel_loop [collapse(N)] must be perfectly nested. The loop counter variable of those loops must be of either type int or unsigned, and the stride must be known at compile time.

• If your application executes code on the target and host in parallel, you need to ensure that the host and the target do not modify the same cache lines to avoid the false sharing problem. For example, you can pad variables passed to the pin clause to a multiple of the cache line size, or if the host and the target operate on the same array, correspondingly organize the write access in your parallel offload code. Applying __declspec(avoid_false_share) for a variable ensures it is aligned and padded such that it is not subject to false sharing with any other variable.

• Recursive calls are not supported.

• The header file math.h expands single precision functions, such as sinf to double precision, and the compiler is not always able to convert them back, which may lead to performance problems or even compiler failures. To work around this problem, use mathimf.h instead.

• The compiler supports only a subset of math functions, which either map directly to the Intel® Graphics Technology instruction set architecture when possible, or are implemented in the SVML library supplied with the compiler. Only the following functions are supported:

  • acos/acosf

  • acosh/acoshf

  • asin/asinf

  • asinh/asinhf

  • atan/atanf

  • atanh/atanhf

  • cbrt/cbrtf

  • sqrt/sqrtf

  • ceil/ceilf

  • cos/cosf

  • erf/erff

  • erfc/erfcf

  • exp/expf

  • exp10/exp10f

  • exp2/exp2f

  • expm1/expm1f

  • fabs/fabsf

  • floor/floorf

  • invsqrt/invsqrtf

  • log/logf

  • log10/log10f

  • log1p/log1pf

  • log2/log2f

  • nearbyint/nearbyintf

  • rint/rintf

  • round/roundf

  • sin/sinf

  • sinh/sinhf

  • tan/tanf

  • tanh/tanhf

  • trunk/truncf

  • copysign/copysignf

  • atan2/atan2f

  • fmax/fmaxf

  • fmin/fminf

  • hypot/hypotf

  • pow/powf

• Double precision division is also supported and is translated to a call to an SVML function.

• The compiler does not support Variable Length Array allocation in heterogeneous code. For example, instead of using float myArray[variableSize];, where variableSize is a variable, use float myArray[CONSTANT_SIZE]; where CONSTANT_SIZE is a compile-time constant.

• Code linking is not supported in target code, so you cannot build a library of target code in binary form and then use it in your or third party applications. You also cannot call a target function in a compilation unit from other code compiled for the target in a different compilation unit.

• 64-bit integer (long long) operations are not supported in target code.

• long double operations are not supported in target code.

• longjump/setjump is not supported in target code.

• Indirect control flow is not supported in target code, including:

  • Function pointers, taking address of a function, calling a function by pointers

  • Calls to virtual function

  Switch statements are supported in target code.

• Exceptions are not allowed in target code.

• RTTI is not supported in target code.

• Functions with variable number of parameters (…) are not supported in target code.

See Also