For testing purposes, I’ve only one thread that execute this kernel, so I can’t have race conditions. However, I’ll try to take single values and check their correctness (with the first method).
@eyalhir74: I’ve made the test and the values taken are corrected.
@kr1_karin: You’re right! I’ve made a big mistake using the same texture reference. Now I’ve the same results at every kernel launch, but still wrong.
How you can see, I’m using float2 for represent complex numbers. Is correct access to them by using x coordinate and y coordinate like real part and imaginary part in complex numbers, respectively?
Yeah it’s correct.
I don’t know what your treatment is on these complex numbers but using a texture of float2 to represent them and tex1Dfetch(tex, n) to access them (with texsig.x the real part and texsig.y the complex one), is perfectly right.
Making some tries, I’ve noted in kernel these arrays doesn’t have right values. For example, in Energy array all its elements must be equals to 1e-2f; instead it has random values. I don’t know what’s wrong. :(
Making some tries, I’ve noted in kernel these arrays doesn’t have right values. For example, in Energy array all its elements must be equals to 1e-2f; instead it has random values. I don’t know what’s wrong. :(