colorapp CL_INVALID_KERNEL_NAME

[SmartRoof]

I have tried sobel and its all good. But, when i try colorAPP. I get the following error.

ERROR: CL_INVALID_KERNEL_NAME Line 246

However, i checked the host code. The name is same as the files name. @thinkoco help please :)

[thinkoco]

@SmartRoof Maybe，you can replace the opencl.rbf in SD card FAT partition with the compiled opencl.rbf in the compiled binary folder . Keep the grayKernel, grayKernel.aocx and opencl.rbf sync. Also，the runtime version should be 16.1.

[zhao-lun]

@thinkoco Can i ask what relationship between opencl and rbf? I know Opencl kernel aocx reprogram the soft logics but how about rbf file?

[thinkoco]

@johnnydept yes，the aocx contains the fpga logic configrations. It's dynamic configuration. Raw binary file (rbf) is usually used to configure before linux kernel boot up . Borth of the two file are wite to fpga by fpga-manager in hps . When compiling the xxx.cl，the generated top.rbf contains the same xxx.cl kernel logic and the added vip core loigc. So，we can used the top.rbf without aocx dynamic configuration. What's more，the dynamic configuration will flush the fpga logic and the altera video ip driver will lost the control of hardware. (Cyclone V is not support partial reconfiguration)

[thinkoco]

@SmartRoof Hi，I have checked . You need keep the opencl.rbf sync with the graykernel.aocx. Rename your genareted top.rbf to opencl.rbf and copy to the SD card(delete the original opencl.rbf). Then run colorApp host applicaton.

[zhao-lun]

@thinkoco Hi, correct me if im wrong, So both aocx and rbf have the same function? Because they reprogram the soft logic (rbf by reboot, aocx by typing aocl program). Also, I wonder why u need to sync aocx with rbf file? Give they have the same function.

[thinkoco]

@johnnydept Although,no need programing the aocx，the opencl host application still checks the aocx file. No aocx file will get error. I'm not sure why. Here are more details about CL_CONTEXT_COMPILER_MODE flag.

CL_CONTEXT_COMPILER_MODE_PRELOADED_BINARY_ONLY_ALTERA - The device is assumed to already have a program loaded before the first OpenCL APIs are invoked. All cl_program objects behave as if they refer to the preloaded device binary. The clBuildProgram API method always succeeds when compiling for this device, but does not produce an executable device binary. The clCreateProgramWithBinary does not validate the provided binary. It always succeeds provided its arguments are well-formed. The data returned by the CL_PROGRAM_BINARIES query for clGetProgramInfo is unspecified. It may not be a valid device binary.

[zhao-lun]

@thinkoco Hi, Can i ask another question. The BSP you build, de1soc_sharedonly_vga. How does this BSP relate to OpenCL kernel aocx build?

[thinkoco]

@johnnydept

It's seems that, aocx file = aoco file + fpga.bin

First stage (“aoc -c demo.cl”) , copy the de1soc_sharedonly_vga hardware template to demo.cl folder and generate demo.aoco (Altera Offline Compiler Object file) which contains opencl kernel,board_spec.xml,some descriptions and so on.

Second stage(aoc demo.aoco), use the generated demo.aoco (kernel + hardware template) to build a hardware configuration file, called the Altera Offline Compiler Executable file (.aocx), that targets the FPGA.

Maybe，u can get more information by the scripts in hardware template scripts folder , such as create_fpga_bin.tcl.