GPU offloading runtime error

[Steve_K_4]

I am getting the following errors when I try to use the graphics offloading capabilities of the v16 compiler.

GFX(17:12:12): WARNING: gfx-binary is not found
GFX(17:12:12): WARNING: trying to load .isa file
GFX(17:12:12): ERROR: Can't find .isa file
GFX(17:12:12): FATAL ERROR: can't initialize gfx program

I am using Visual Studio 2015. My .exe is a .NET app which calls a managed DLL, which is linked with my native code compiled with the Intel compiler and which contains the offload code. It works if I do not offload to the GPU. It also works if I just create a simple .exe that is only an Intel C++ project with offloaded code.

Is there any technical information about how the graphics offloading works at runtime, what is linked in, what I can do to dump info on the DLL, etc. All the docs I can find online are very high level and superficial with regards to actual runtime behavior.

[KitturGanesh]

Hi Steve,
The error seen by you as expected occurs if the DLL containing offload code is linked using VS “link” directly instead of Intel’s “xilink” which knows about target code. So, you must use xilink for linking instead of VS link per-se.  That said, if a source module contains an offload region and is linked into a DLL, the target kernel must be embedded into the DLL such that the offload runtime can located the kernel.

For example compiling dll1.cpp which contains offload code and the dumping the sections of the object file will show it contains a non-loadable section .gfxobj which is the target object.

icl –c dll1.cpp
…
dumpbin dll1.obj
%> dumpbin dll1.obj
Microsoft (R) COFF/PE Dumper Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.
Dump of file dll1.obj
File Type: COFF OBJECT
 Summary
  CA .drectve
  2CA0 .gfxobj
  30 .pdata
   B0 .rdata
   4D0 .text
   44 xdata

Linking the object into a DLL the VS linker does not know about the target section and it is ignored.

link /dll dll1.obj
dumpbin dll1.dll
% dumpbin dll1.dll
Microsoft (R) COFF/PE Dumper Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.
 

Dump of file dll1.dll
File Type: DLL
 Summary
3000 .data
1000 .pdata
3000 .rdata
1000 .reloc
9000 .text

An application linked against the DLL will see the issue as below:

GFX(11:50:19): WARNING: gfx-binary is not found

GFX(11:50:19): WARNING: trying to load .isa file

GFX(11:50:19): ERROR: Can't find .isa file

GFX(11:50:19): FATAL ERROR: can't initialize gfx program

Linking the DLL using the Intel linker driver (xilink), which knows to look for target sections, it can be seen that the target sections and kernel are embedded in the final .DLL

xilink /dll dll1.obj
…
dumpbin dll1.dll
Microsoft (R) COFF/PE Dumper Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file dll1.dll
File Type: DLL
Summary
    3000 .data
    2000 .datagfx
    3000 .gfx bin
    1000 .gfxkern
    1000 .gfxvars
    1000 .pdata
    3000 .rdata
    1000 .reloc
     9000 .text

Now at runtime the host code in the DLL that does the target offload can locate the kernel in the DLL.

So the issue appears to be that the Intel compiler driver or linker driver is not used to link the DLL. This can be checked using dumpbin to look for the GFX sections.  

The following links related to offload programming model 

https://software.intel.com/en-us/forums/intel-c-compiler/topic/598242
https://software.intel.com/en-us/articles/how-to-offload-computation-to-intelr-graphics-technology
https://software.intel.com/en-us/articles/code-generation-options-for-intelr-graphics-technology

And, I’ve passed on your feedback on adding more content (related to runtime that you refer) than just the programming model content that’s available and will keep you updated. Appreciate much for bringing this to our attention.  

[KitturGanesh]

Steve, any update? I assume the previous communication resolves the issue, thanks.

_Kittur 

[Ben_Rush]

_Kittur, 

This actually hasn't been resolved. This issue is still occurring. I'm also fairly confident the linker that I'm using IS the Intel link and not the Visual Studio linker. 

An example output from the build log is: 

 C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016\windows\bin\Intel64\xilink.exe -qm64 /OUT:"C:\repos\CVPrototype\IntelOptimized\x64\Release\DecisionTreeTestBed.exe" /INCREMENTAL:NO /NOLOGO decisiontree.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /manifest:embed /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\repos\CVPrototype\IntelOptimized\x64\Release\DecisionTreeTestBed.pdb" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:\repos\CVPrototype\IntelOptimized\x64\Release\DecisionTreeTestBed.lib" /MACHINE:X64 x64\Release\DecisionTreeTestBed.obj
                     x64\Release\stdafx.obj (TaskId:30)
                     Tracking command: (TaskId:30)
                     C:\Program Files (x86)\MSBuild\14.0\bin\amd64\Tracker.exe /a /d "C:\Program Files (x86)\MSBuild\14.0\bin\amd64\FileTracker.dll" /i C:\repos\CVPrototype\IntelOptimized\DecisionTreeTestBed\x64\Release\Decision.2B8E0A0F.tlog /r "C:\REPOS\CVPROTOTYPE\INTELOPTIMIZED\DECISIONTREETESTBED\X64\RELEASE\DECISIONTREETESTBED.OBJ|C:\REPOS\CVPROTOTYPE\INTELOPTIMIZED\DECISIONTREETESTBED\X64\RELEASE\STDAFX.OBJ" /b MSBuildConsole_CancelEvente5ab3351f0274a73b1856b0a81065c30  /c "C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016\windows\bin\Intel64\xilink.exe"  -qm64 /OUT:"C:\repos\CVPrototype\IntelOptimized\x64\Release\DecisionTreeTestBed.exe" /INCREMENTAL:NO /NOLOGO decisiontree.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /manifest:embed /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\repos\CVPrototype\IntelOptimized\x64\Release\DecisionTreeTestBed.pdb" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:\repos\CVPrototype\IntelOptimized\x64\Release\DecisionTreeTestBed.lib" /MACHINE:X64 x64\Release\DecisionTreeTestBed.obj
                     x64\Release\stdafx.obj (TaskId:30)
                     Output Property: LinkSkippedExecution=False (TaskId:30)
                   Done executing task "XILINK". (TaskId:30)

But I still get the same error as Steve above. Same situation: Visual Studio 2015. I'm using the update 2 of the compiler, v16. A search of the build log for visual studio's linker (link.exe) shows nothing, whereas I find several references to xilink.exe. 

[Ben_Rush]

...So I believe the problem to be related to this situation: 

1) Someone has an EXE project in Visual Studio that compiles with the Intel Compiler. The EXE does not do any GPU offloading. 
2) Someone has a LIB project in Visual Studio that compiles with the Intel Compiler. The LIB file DOES do GPU offloading. 
3) The EXE project is built, and for some reason the gfx linker isn't invoked. 
4) The LIB project is built, but it's built with a different linker: xilib-xilink-gfx (I'm seeing a bunch of log files with this prefix in my build directory). 

The result is that the gfx section never gets spat into the PE file for the EXE itself. When looking at the log files for my executable I'm seeing no "xilink-gfx_linker-ld.*" files. But I'm seeing those in the LIB file's log directory. 

When I insert some basic GFX offloading code in the EXE, the thing compiles and the gfx section is inserted into the PE. I NOW see a bunch of "xilink-gfx" log files being generated. Things then run. 

Now when I do GFX_PRINT_DIAG I see only 1 kernel in the EXE, but there OUGHT to be another kernel that came along with the LIB file itself. So that tells me I'm NOT generating a GFX section for the lib file, but I AM generating one for the EXE file. What gives? 

Indeed, after adding graphics offloading code into the EXE, my PE file now has the gfx* sections: 
 

C:\Users\brush\Documents\Visual Studio 2015\Projects\IntelTestbed\x64\Release>dumpbin IntelTestbed.exe
Microsoft (R) COFF/PE Dumper Version 14.00.23506.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file IntelTestbed.exe

File Type: EXECUTABLE IMAGE

  Summary

        3000 .data
        1000 .data1
        2000 .datagfx
        1000 .debug_o
        1000 .gfids
       16000 .gfx bin
        1000 .gfxkern
        1000 .gfxvars
        1000 .pdata
        6000 .rdata
        1000 .reloc
        1000 .rsrc
       10000 .text
        2000 _RDATA

But the lib file that has GFX offloading code in it, does not have those sections: 

 

C:\Users\brush\Documents\Visual Studio 2015\Projects\IntelTestbed\x64\Release>dumpbin IntelTestLib.lib
Microsoft (R) COFF/PE Dumper Version 14.00.23506.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file IntelTestLib.lib

File Type: LIBRARY

  Summary

          18 .bss
        1250 .data
        16D8 .data1
       1D108 .debug$S
       35C58 .debug$T
        1C27 .debug_opt_report
         4DA .drectve
         B4C .pdata
         550 .rdata
        BA50 .text
        1830 .xdata
      D1868A _ILDATA

So the question is: what's different when building a LIB file vs. an EXE file with the Intel compiler? It appears as though the Intel compiler itself is just stripping out the GFX section for a lib file. I see no other reason the log files would explicitly mention the various intel linkers for both projects but NOT use them (which is the original theory you proposed). 

[Ben_Rush]

Upon even further inspection, it seem as though the compiler itself never generates the gfx section. If I have offload code in a static lib, build it with the intel compiler, and run dumpbin on it, I see no .gfxobj section. Yet there is, indeed, #pragma offload(target(gfx)) code in my static lib. 

[Ben_Rush]

Finally resolved. I wasn't looking at the warnings. 

I was getting this on my LIB file project: 
Warning    #2570    *GFX* function has not been declared with compatible "target" attribute   

The result was the compiler was then deciding to not generate GPU code for the warning. This generated a static lib with CPU-only code. Which was linked to by the EXE. For some reason enough of the fact I was trying to compile to the GPU must have been "carried" along with the LIB file, which resulted in the runtime errors mentioned at the start of the thread. 

[KitturGanesh]

Hi Ben,
Great, thanks for the detailed analysis. Indeed, was interesting to read through your posts leading to  the resolution, thanks much.
_Cheers,
Kittur