1 Solution
Yes you are right about group zero 
I should go and rest I guess 
There is something strange in your explanation, if count
What about printing it right after atomic add? If what you say is true, you should see it zero right? Do you see it zero?
if(glob%6==1) {atomic_add(&count
I can run and see what your program is doing if you can make a small test case. But I have no other ideas about what might be wrong at this point 
Normally a perfect test case is a program which is as simple as possible yet still can cause the problem, with some instructions on how you are compiling and running it obviously You can attach it to the thread so everybody who is interested can have a look.
On another note
| clGetDeviceInfo(device_id, CL_DEVICE_MAX_COMPUTE_UNITS, sizeof(int),(void *) &l, NULL); |
| count = clCreateBuffer(context, CL_MEM_READ_WRITE, sizeof(int)*l, NULL, NULL); |
For a CPU the max compute units is the core count....but you are using:
k = get_group_id(0);
The group id can be larger than the core count, it is global/local although for you it shouldnt be a problem for this test case since you seem to have: (and probably dual-core or more core procesor so...)
| local = 6 |
| global = local*2; |
I really have to suggest cleaning up the code and putting those kernels out from there. It is not very easy to follow what is going on...
Actually, it does segmentation fault and nothing comes out. I ran it with valgrind and I think you are copying some data from unallocated memory spaces, and using unitialized data etc. In my opinion your problem is not due to your kernel itself (at least you seem to have much more serious problems in the host code), you should try to clean up your code and make it more readable. Maybe you can find the problem yourself also This is what I had when I tried to run your code:
$ ./hello -parallel -grid 3 4
Generating 2D grid with 3 rows and 4 columns, for 12 vertices in all.
Time to generate grid graph is 50.927097 sec.
Graph has 12 vertices and 34 edges.
firstnbr = 0 2 5 8 10 13 17 21 24 26 29 32 34
nbr = 1 4 0 2 5 1 3 6 2 7 0 5 8 1 4 6 9 2 5 7 10 3 6 11 4 9 5 8 10 6 9 11 7 10
number of edges 12
Running parallel betweenness centrality...
1 devices
Device name = Intel(R) Xeon(R) CPU E5430 @ 2.66GHz; Number of compute units 8; Number of workitems per workgroup 1024
Pot sa am 1024 workitems pe workgroup
Segmentation fault (core dumped)
$
I had good luck with the following C code for loading from file:
printf("\nTrying to use OpenCL source file %s\n", CLFILE);
int fd = open(CLFILE, O_RDONLY);
if (fd == -1) {
fprintf(stderr, "Couldn't open the source file\n");
exit(1);
}
struct stat filestat;
if (fstat(fd, &filestat) == -1) {
fprintf(stderr, "Couldn't stat the source file\n");
exit(1);
}
size_t size = filestat.st_size;
const char *data = (char*) mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
printf("Mapped the source file (%d bytes) to %p\n", size, data);
cl_program program = clCreateProgramWithSource(context, 1, &data, &size, &err);
if (err != CL_SUCCESS) {
fprintf(stderr, "Couldn't create the OpenCL program\n");
exit(1);
}
Good luck
Like I said, your program was generating segmentation faults anyway. Putting kernel to separate file probably wont help.
But in this specific case, you have a /* on line 103 but never a */ which matches it. ( I believe you need */ on lline 141).
Then after this, there are some other problems but you should see them in the error log (it will print them same as below).
I cant debug your program for you. You should put some effort to finding problems and making it properly readable will make it easier for you. You could maybe spot a */ missing if you didnt have so many stuff on a single line on a single line 103:
barrier(CLK_LOCAL_MEM_FENCE);if(glob!=0&&glob!=1&&glob!=2&&glob!=3) BC[glob] = atomic_xchg(&sigma[glob],sigma[glob]);}; /*
Trying to use OpenCL source file BCkernel.cl
Mapped the source file (9087 bytes) to 0x7fd92f41a000
Error: Failed to build program executable!
CL_BUILD_PROGRAM_FAILURE
"/tmp/OCLzKCteO.cl", line 47: error: unrecognized token
pozition_local = atomic_add(pozition,0); nr = nr +1;\n
^
"/tmp/OCLzKCteO.cl", line 47: error: expected an expression
pozition_local = atomic_add(pozition,0); nr = nr +1;\n
^
"/tmp/OCLzKCteO.cl", line 85: error: function "GetSemaphor2" declared
implicitly
GetSemaphor2(&sem[0]); temporal = atomic_xchg(&sigma[node],0); temporal2=atomic_xchg(&sigma[root],0);
^
"/tmp/OCLzKCteO.cl", line 86: error: function "ReleaseSemaphor2" declared
implicitly
atomic_xchg(&sigma[node],temporal+temporal2);atomic_xchg(&sigma[root],temporal2);ReleaseSemaphor2(&sem[0]);
^
"/tmp/OCLzKCteO.cl", line 36: warning: variable "ft" was declared but never
referenced
float ft,aux1,delta_temp;
^
"/tmp/OCLzKCteO.cl", line 36: warning: variable "aux1" was declared but never
referenced
float ft,aux1,delta_temp;
^
"/tmp/OCLzKCteO.cl", line 36: warning: variable "delta_temp" was declared but
never referenced
float ft,aux1,delta_temp;
^
4 errors detected in the compilation of "/tmp/OCLzKCteO.cl".
Internal error: clc compiler invocation failed.
Perhaps the compiler just does not understand a */ is missing for closing the comments and bailing out altogether. It might be a bug actually, I will check it later and try to report to AMD if I can repeat the issue and if I dont forget
t-man wrote:
nr_roots gets increased only in 1 line, at is increased by thread 0 of each group, so there will be no other thread increasing it. Is that logic ok?
No your thread goes all the way back to
| while ( found_local != 0){ |
then start from there again and re-increase it sometimes
Also you are checking for local id, where thread with same local id exists twice since you have two groups.
| if(i==0) { | level_local = atomic_add(nr_level,0); atomic_xchg(found,0); |
| pozition_local = atomic_add(pozition,0); | |
| nr_roots = atomic_add(&level[level_local],0)/j; count = 0; rest = atomic_add(&level[level_local],0)%j; | |
| if(k<rest) nr_roots = nr_roots + 1; | |
| } |
If you put some printf statements to above area, you can see how many times you are increasing nr_roots.... it definitely becomes 2 at some point.
Or maybe I dont understand what you are trying to explain maybe somebody else can help further somehow...I dont think I can correct your code (basically because I dont seem to understand what it should be doing exactly)
I guess you just have to wait if somebody is interested to help your problem. Your code is little confusing for my taste
For example I dont understand why you have nr_roots = atomic_add(&level[level_local],0) / j (why atomic add 0? makes no sense?)
Then sometimes when k < rest you increase nr_roots -> if(k<rest) nr_roots = nr_roots + 1; (and it is increasing it sometimes in your test case also)
Of course if you put me as co-author in your thesis, I can write your program from scratch hehe ok joking!
I still think nr_roots is increased in sort of a random manner in your code. But if you say it is suppose to be like that, who am I to argue You have a while(count
t-man wrote:
Hey yurtesen!
I noticed that you can use printf in your kernel. How did you do that as I cannot? Thanks!
Yes, I told you to use printf's to check the problem several times
Are you using AMDs SDK? because strangely it simply worked with AMDs SDK without any other code change. (I tested on CPU only, but it should work on GPU also).
Normally you should add the following pragma to get printf to be recognized:
#pragma OPENCL EXTENSION cl_amd_printf : enable
I am not sure why it worked without it in your code. You can also use it with GPUs. Also you should be able to debug your code using CodeXL, even line by line I think
t-man wrote:
#pragma OPENCL EXTENSION cl_amd_printf : enable this solved the problem thank you!
Question about the CodeXL: Does it work if I have a Intel dual core?
It might work I guess, you simply wont have access to CPU performance counters for profiling. Let us know if you can get it working. Intel has some products but they cost a lot and I am not sure which product can debug OpenCL, you can maybe get a 30day trial for some of the products. Next time you might consider getting an AMD CPU, Intel is very expensive
Also, wasnt I also right that nr_roots get incremented? (perhaps due to nr_level being incremented, but never the less) ?
so the problem was as follows:
1st level workgroup 0 increments nr_level
1st level workgroup 1 checks nodes on the wrong level getting a wrong nr_roots as well . So you were right. Thanks for everything!
Going to try the debugger, have met some other interesting bugs now
