A very confused question in oceanFFT sample

Hi,guys
In this sample,there is a piece of code as below:

const unsigned int meshSize = 256;
const unsigned int spectrumW = meshSize +4;
const unsigned int spectrumH = meshSize +1;

I don’t understand why spectrumW and spectrumH didn’t use the same value as meshSize,it seems like unuseful.
But I change its value to 256,the program triggered a breakpoint at the position as below:

createVBO(&heightVertexBuffer, meshSize*meshSize*sizeof(float));
    checkCudaErrors(cudaGraphicsGLRegisterBuffer(&cuda_heightVB_resource, heightVertexBuffer, cudaGraphicsMapFlagsWriteDiscard));

I still can’t find what cause the problem.
Could someone give me some hints?
Thanks!

Although I’ve not fully parsed the application, it seems evident to me that the frequency domain representation of the wave data needs to be dimensionally larger than the spatial domain.

It’s also not entirely clear what changes you have made, nor do I know what you mean by “program triggered a breakpoint”. If you didn’t set any breakpoints, I’m not sure how you could have triggered one.

In any event, if you change either spectrumW or spectrumH to be 256, you will immediately run into a problem in the generate_h0 code, before you get to any OpenGL activity or interop.

If you run the program normally (i.e. with no command line switches) the routine runGraphicsTest will be entered. In this routine we have:

// allocate memory
    int spectrumSize = spectrumW*spectrumH*sizeof(float2);
    checkCudaErrors(cudaMalloc((void **)&d_h0, spectrumSize));
    h_h0 = (float2 *) malloc(spectrumSize);
    generate_h0(h_h0);

If spectrumW or spectrumH are set to 256, we are going to run into trouble in generate_h0:

// Generate base heightfield in frequency space
void generate_h0(float2 *h0)
{
    for (unsigned int y = 0; y<=meshSize; y++)
    {
        for (unsigned int x = 0; x<=meshSize; x++)
        {

where we see that the iteration indices x and y are compared to be less than or equal to meshSize. This means that both spectrumH and spectrumW had better be at least meshSize + 1 (i.e. at least 257) or we are going to run into invalid accesses in this host routine and therefore seg faults.

And I observe seg faults when I run the code with either spectrumH or spectrumW equal to 256.

If you’re running this code in a debugger, I would expect a failure here. However if you don’t get a failure here, I suppose it’s possible that in your setup things are simply getting corrupted, and this corruption makes itself evident later on a function call.

In any event, simply changing spectrumH or spectrumW to be equal to meshSize (i.e. equal to 256) cannot possibly be correct for at least the issue stated above with meshSize.

And I suspect that the designer of this code chose a frequency domain dimension larger than the spatial domain data to meet some need of the simulation, but I don’t have a specific reason why it was written this way.

Thank you very much.
It is good enough to explain the problem.