Sign in to follow this  

DirectCompute texture sampling sometimes returns zero?

Recommended Posts

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?

Share this post

Link to post
Share on other sites
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?

Share this post

Link to post
Share on other sites
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).

Share this post

Link to post
Share on other sites
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?

Share this post

Link to post
Share on other sites

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???

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this