lkedward / focal Goto Github PK

Make compilation fails on Apple Silicon:

gfortran -std=f2008 -fimplicit-none -J../mod/ -g -Og -C -Wall -fbounds-check -fbacktrace -ffpe-trap=invalid,zero,overflow  -c Focal_Test_Utils.f90 -o ../obj/Focal_Test_Utils.o
gfortran -std=f2008 -fimplicit-none -J../mod/ -g -Og -C -Wall -fbounds-check -fbacktrace -ffpe-trap=invalid,zero,overflow  -c testExample.f90 -o ../obj/testExample.o
mkdir build_testExample_cl
cp testExample.cl build_testExample_cl/fclKernels.cl
cd build_testExample_cl; ld -r -b binary fclKernels.cl -o ../../obj/testExample.cl.o; rm fclKernels.cl
ld: warning: option -b is obsolete and being ignored
ld: file not found: binary
rm -rf build_testExample_cl
gfortran ../obj/testExample.o ../obj/testExample.cl.o ../obj/Focal_Test_Utils.o -L../lib -lFocaldbg -g -L/usr/lib/ -lOpenCL -o ../bin/testExample
ld: file not found: ../obj/testExample.cl.o
collect2: error: ld returned 1 exit status
make[1]: *** [../bin/testExample] Error 1
make: *** [test] Error 2

Looks like ld is being used in an obsolete way in the make file.

Would be really great to have a platform independent build system for this project like CMake. I see the other related issue #14 .

Latest ifort doesn't seem to like the procedure pointer used for implementing a custom error handler.
Fix will be to wrap the call in a module procedure instead of calling the procedure pointer directly.

I am trying to compile focal and run your example using vs2019 + intel fortran(2021) on windows. Then I found some problems (while it works fine on ubuntu):

1. Compilation of focal and 'sum.f90' is OK. But when debuging, a very strange exception was thrown :

   Access violation at 0x0000000000000000.

After tons of investigation, I found it was caused by the using of function "fclErrorHandler()". Replace it with "fclDefaultErrorHandler()" throughout the code will fix this problem.

After reading the source code, I guess you want the user to redirect the default handler to his own one. But I have no idea why the code failed with intel fortran (even with f2018 semantics).

2. Afer the first problem, I came across a harder one and stuck here.

When debuging, "sumKernel = fclGetProgramKernel(prog,'sum')"(sum.f90 line 31) get errorcode 46.

The exact failure point is "kern%cl_kernel = clCreateKernel(prog%cl_program,C_LOC(c_name),errcode)"(fcl_Setup.f90 line 583). But I do not know why.

By comparing fortran code to my c++ code, It seems that the problem is caused by sum.f90 line 30:

errcode = clBuildProgram(prog%cl_program,0, &
C_NULL_PTR,C_LOC(c_options),C_NULL_FUNPTR,C_NULL_PTR)

line 501, in function :fclCompileProgram_1 () focal_Setup.f90. The 2nd parameter should be the number of total platforms(devices) and the 3rd should be the pointer to the device

//OpenCL source
extern CL_API_ENTRY cl_int CL_API_CALL
clBuildProgram(cl_program program,
cl_uint num_devices,
const cl_device_id * device_list,
const char * options,
void (CL_CALLBACK * pfn_notify)(cl_program program,
void * user_data),
void * user_data) CL_API_SUFFIX__VERSION_1_0;

I use c/c++ most and I'm new to fortran. So I'm not sure if this is the point. Moreover, I do not know how to modify the code to test.

These problems confused me quite a long time. I am using fortran just to integrate opencl into some very old fortran code to improve the performance..

Hello good sir,
I love your project, as it makes opencl significantly easier to work with, competing directly with the likes of cuda, sycl, and rocm-hip.

I'd like to start using it heavily on my research, but it would be too much of a hassle to use makefiles. It would be nice if I could just use your repository as a Meson subproject. It will import all of the library, and the compiler flags will then be handled automaticaly. It is a genius piece of work.

Of course I can always make a fork and maintain it in parallel, but it would only undermine your efforts, so I looking for the collaboration route.

Thx for your brilliant work!