image shifting inaccurate using CG

I could not find anywhere else on this forum that fits my question better. If you know another place i should post my question. Please let me know. Thanks.

Description:
I am using CG to do some image processing kind of work. I notice the following. When I send a matrix to the texture memory and then use the CG code to do nothing buy shifting the matrix and return that value, I notice it does not always do that correctly. This does not occur if matrix is small, e.g. 50x50 by become very frequent if the matrix is relative big, e.g. 20x4438.

My shading language version is 1.20 Nvidia via Cg compiler.
My renderer is GeForce 8800 GTX/PCI/SSE2
Memory: 736 MB
test code in http://commnet.ece.northwestern.edu/~jqchen/tmp/testcg.rar

I have attached the following files

  1. testcg.cpp - the main function
  2. testcg.cg - the test cg script
  3. datain.txt - the example datain that shows the problem. It contains random numbers and I compute the difference between the shifted output of the CG program and the known ground truth (excluding the last tens of columns to avoid difference in padding for out of range data).
  4. hearder and lib files for compiling.

notes:1. the program can also take data format in mat (matlab mat file). In that case you just need to turn flat ‘‘usetxt’’ to 0.
2. If you do not have the required including files and head file simply keep usetxt being 1 and removing
#include “mat.h” and
function readmat() - the last function in the cpp file.

       3. once you build the code, type  cmd -u to see how to use it.

There are two things you can experiment

  1. send data to texture just once, then keep read the data out, 2. keep send the same data to texture, read it out, then clear the texture, then redo the whole procedure.

In both case, you see the problem, while the first case shows more randomly like difference with the 2nd, the output seems to converge to a dataout with each row being same values.

Choose between two cases with flag " reloading"

The program force two case to run a couple of hundreds of times (600 e.g). The program prints the difference on the screen (any value other than zero signal problem). The program will stop when a difference is detected. and save current output to a dataout.txt

Please help.

I haven’t looked at your code, but in general you can’t expect texture filtering operations to exactly match a full precision CPU implementation. In particular, the texture hardware only has 9 bits of sub-texel precision when filtering (so you only get 512 possible values between the texels).

Hope this helps.

I am not sure I understand what you wrote. Do you mean I cannot accurately shift if the shift amount is more than 512 or I cannot accurately shift if the block size is bigger than 512x512? I am not trying to shift that much. My shift is within 40 elements in each direction. My block size is big as I am trying to process a 16 M image and try to use as less block as the GPU allows me to save time for data porting in and out the GPU.

Thank you.

I was assuming you were using linear texture filtering, but from your code it appears you’re not, so ignore everything I just said!

Your code doesn’t compile because it is missing the “mat.h” file.

Note that these forums are intended for CUDA questions only.

Thank you for you reply. I am aware I am not posting the question at the best place but I really didn’t find anywhere else on this forum that fit my question.

the problem with mat.h can be fixed as i mentioned in the post

  1. If you do not have the required including files and head file simply keep usetxt being 1 and removing
    #include “mat.h” and
    function readmat() - the last function in the cpp file

What I tried to do (in this test code) is very simple. I transfer an image (single channel) to GPU, let it shift it by certain amount (e.g. 10 in x, 0 in y), then return the shifted image and I notice it didn’t do that correctly when image size goes bigger. This is very fundamental operation for the following computation I intend to do.

Thank you very much.