Closed Ferruck closed 8 years ago
I didn't look at the source, but look for memory reuse, global variables and problems with streaming / synchronization.
If the first argument of addTask is _h_mem, so file.first in this case, then aren't you calling shrinkWrap with the same pointer to rIntensity multiple times? Note that rIntensity is both input and output host memory, If you are calling it 30 times with the same pointer then the first finished thread overwrites input values (also needed inside the cycle) of other threads. That's my 10-minute-guess, would have to look and test it, if what I'm saying is correct.
I fear that you're right, @mxmlnkn . I'll test that right now and if it's right I'm incredibly sorry for that dumb fault.
Don't sweat it. The documentation is a bit incomplete and has some inconsistencies. In the first place functions mentioned in .h shouldn't be documented in their bodies like I did with cudaShrinkWrap.
Indeed that was the error. Sorry for that. It's not your fault as I knew that the pointer needs to be renewed, just forgot it yesterday. I guess I was a little bit tired.
I now get the independant results I wanted, but the look all nearly the same, but thats another question.
these don't like results at all, I mean shouldn't you want to get some structure in return? I.e. what kind of input-data did you use?
When calling the algorithm multiple times at once like in the following
the results get worse with each loop. After a few loops only a black image is returned (have a look at the attached images, sorry for the inversed order). Also the algorithm's output switches to
[Error -nan/1e-05] [Cycle 0/2]
for each loop.Fine tuning of the shrink wrap parameters have not solved this issue for me.
It seems like the different algorithm calls influence each other.