tex3D and cudaReadModeNormalizedFloat

I’m experiencing a strange issue with tex3D() when using a 3D array of unsigned shorts. I’m using cudaReadModeNormalizedFloat and cudaFilterModeLinear. I’ve based my test program on the simpleTexture3D sample program. Everything seems to be working fine except I’ve noticed that when I rescale the values returned by tex3D() by multiplying by 65535.0 I always get an exact integer. If I initialize my array with a gradient where the difference between adjacent pixels is 1 then I would have expected that if I used tex3D to interpolate the array to double its original size then I would get half-integer values. But I still only get integer values (in bands two pixels wide). If I use an array of floats and the cudaReadModeElementType instead then I don’t have this problem but I need twice as much memory. Is this by design and is it documented somewhere?

Are you taking into consideration that texture interpolation uses a fixed-point representation with only eight fractional bits internally? This is documented in the Programming Guide, I think.

I seem to recall that there was an almost identical question regarding interpolation with tex2D a while ago, and on further analysis the granularity of the interpolation was the issue. Let me see whether I can find that. [Later:] This is the previous thread I was thinking off:

[url]https://devtalk.nvidia.com/default/topic/783349/texture-interpolation-with-16-bit-integers-types-rounding-to-nearest-value-/[/url]

Thanks for the reply and sorry I missed the previous post (I did try searching).

I was aware of the fixed-point representation but as far as I can tell it doesn’t explain my observations. The documentation says:

tex(x)=(1−α)T[i]+αT[i+1]

where α is in 1.8 fixed-point representation. Therefore α has granularity of 1/256. So if α = 1/256, T[i] = 0 and T[i+1] = 1 then tex(x) = 1/256 which will then become 1/(256*65535) after normalization to float? Put another way, surely (1−α)T[i], αT[i+1] and tex(x) should all be in x.8 fixed-point representation?

In other words, my understanding was that the fixed-point representation leads to a positional granularity of 1/256 of a pixel whatever the data type.

As it happens, it isn’t a major problem for my actual application but I was doing some tests to check that I was sampling my textures using the correct coordinates and I spent the best part of a day thinking that linear interpolation had completely stopped working.