DirectCompute texture sampling sometimes returns zero?

Started by
6 comments, last by antmck2013 11 years ago
Hi all,
I've been working on some HLSL code for DirectCompute, and I'm finding that randomly a texture sampling will return zero. This is causing all sorts of problems, since I'm using the sampled texel in a differential equation that explodes in a spectacular manner when fed garbage data.

The texture in question is a Texture2D created as DXGI_FORMAT_R32_FLOAT (i.e. a single float for each texel). The texture sampler is defined to clamp on the edge of the texture as well as use D3D11_FILTER_MIN_MAG_MIP_LINEAR. There's a single mip map level.

The HLSL code that does the sampling is as follows:

Texture2D<float> inputTex : register(t0);
SamplerState linSamp : register(s0);
float4 getSSPDerivatives(float range, float depth)
{
float2 tex1;
float2 tex2;
//Find the initial sound speed.
tex1.x = (range / 10000.0);
tex1.y = (depth / 5000.0);
//Find the sound speed a little deeper (finite difference)
tex2.x = (range/10000.0);
tex2.y = ((depth + 10)/5000.0);
float localC = inputTex.SampleLevel(linSamp, tex1,0);

float dcdz = (inputTex.SampleLevel(linSamp, tex2,0) - localC)/10.0;
//Find the sound speed a little farther away (more finite difference)
tex2.x = ((range + 10) /10000.0);
tex2.y = tex1.y;
float dcdr = (inputTex.SampleLevel(linSamp, tex2,0) - localC)/10.0;

return float4(dcdr, dcdz, localC, tex1.y);
}


The symptoms of the problem are that the variable localC, which represents the first texture sampling operation, goes to 0. tex1.y is included in the return for debugging purposes, as it's the only texture coordinate rapidly changing (the X coordinate increases monotonically as the diff EQ marches out in range, whereas the Y coordinate varies based on the diff EQ's previous iteration).

I've been unable to determine why the texture sampling operation returns 0, as there are no 0s in the texture. The texture is currently created as a 2x1024 texel piece, with the two X columns duplicated (eventually the data in the X direction will be different, but I'm just working on getting the Y coords working atm). I've looked at the output of different threads in the shader, and none of them seem to fail at the same iteration step.

Is there anything obviously wrong with my texture sampling function? Is there a limit to the number of texture sampling operations that can be done across all threads in a shader?
Advertisement
Bump...
I've never seen texture sampling functions just randomly return 0. You can try using the REF device to rule out driver/hardware bugs, but it will be slow.
Well I just ran it with the reference driver and the texture sampling operations work. I'm mildly confused now, as I've been running in the hardware driver on two separate machines with different video cards (ATI mobile on one, nVidia GTX 560Ti on the other) and in both cases the texture sampling ops return zero. I'm not sure if it's random or not, I'm just noticing a few correct texture sampling ops then after that it just returns zero regardless of the texture coordinates.

Could it be possible I'm setting up the hardware incorrectly somehow?
Hmm, that is strange. It definitely doesn't sound like a driver bug. Is the texture data static, or is it dynamically generated at runtime by the GPU?
The texture data is generated once at runtime on the CPU and pushed to the GPU. After that nobody writes to the data and only the GPU reads it. I've looked at the texture data itself just before I unmap it and validated it as being what I expect (i.e. it contains no zeros).
Sorry to dredge up an old topic, but I'm still having trouble with this one and I've been around the internet and back to no avail. :(

In looking closer at the reference vs hardware drivers, I found a difference I hadn't noticed before. The very first texture extraction gives a different result, and thus results in a different value for DCDZ (the 2nd term returned by the function above).

In reference, DCDZ turns out positive, in hardware, DCDZ turns out negative, yet they both have the same texture coordinates. I can't be sure if *all* texture returns are different between the two or not, since each iteration depends on the previous one.

What are the differences between how the reference driver does texture lookups and how the hardware driver does it?

I'm having a similar problem. I have a height map that the vertex shader generates y values from, and I have 4 textures to render the terrain with in the pixel shader.

I have a another vertex shader to generate a shadow map. All of that works fine. But adding shadows to the terrain (after texturing) doesn't work. The line where the shadow map is sampled always returns zero. All the other texture sampling works, just not the with the shadow map. I have saved the shadow map texture and it looks fine. The texture co-ords look OK too. I don't understand what is going on. All the other texture sampling is fine - why not this one???

This topic is closed to new replies.

Advertisement