Does texel space offset result in dependent read?
Ok, so here is the problem. I have PCF, and I am doing something like:
[unroll] for (int y = ...; ...; ++y)
[unroll] for (int x = ...; ...; ++x)
tex.Sample(sampler, input.texcoord, int2(x, y));
Everything is fine, unless I want to optimize it and for example do PCF only for shadowed points. I put loops into an if() branch, and the compiler puts texture sampling instructions outside the branch, leaving only arithmetic ones inside. Obviously not what I wanted.
Ok, I had the same issue with D3D9, where texel-space offset needs to be simulated via arithmetic instructions, which causes a dependent read - and this in turn causes a problem with mip level estimation - because if a branch is executed in one pixel in a block (2x2?) of pixels, and is not executed in the other, it is not exactly clear how to compute derivatives - so sampling instructions are moved outside the loop.
This is perfectly sane and clear. And it is solved with using tex2Dlod (or tex2Dgrad) instead of tex2D.
And in my case with D3D10 it is again solved by using SampleLevel instead of Sample. Though I can't find the sane explanation. I pass the texture coordinate which is not dependant (i.e. computed in shader), and I expect the sampling instruction to compute derivative, select mip level and THEN offset by several texels.
Or perhaps texel space offset is specified in the space of the first mip level, not in the space of the used one? But no, DX SDK explicitly states "The offset parameter is added to the texture coordinates, in texel space, relative to each miplevel being accessed."
So, I am wondering - what's the case? Is it the HLSL compiler issue (I can't verify that, because there is no - at least, official - way to convert asm shader into binary one), D3D10 design issue, documentation issue or do I simply miss something?
