Figure out why SDAccel can use kernel without including the signature

[rachitnigam]

@ViviYe mentioned that the kernel signatures have been commented from the header files in the SDAccel port.

There are calls like:

std::string binaryFile = xcl::find_binary_file(device_name,"gemm"); 

in the host file. My best guess is that the make rules build a singular kernel file, use the extern to expose it as a callable function, and then the host uses some sort of OpenCL functions to call them directly.

[sampsyo]

Yeah, that would be consistent with the way that OpenCL works as opposed to the dark magic of SDSoC. In the OpenCL/SDAccel world, you have to explicitly write the code that looks up the device-side interface that the host will send data to. That's unlike SDSoC, which let you make a fake "function call" to the hardware code and then transparently rewrote the call into an explicit lookup/invocation.

So to sum up, the OpenCL host interface does not and cannot know anything about the C type of the hardware "function."

[rachitnigam]

Great! Good to know. This might help remove a bunch of the hacks to make C++ signatures work with Fuse programs.

[sampsyo]

:+1:

I thought of another way to summarize the point I was making: The OpenCL host interface is insensitive to the language that the device code is written in. It might be written in Verilog, for all it knows! So it can't possibly know the C type of the device code it's invoking.