I was talking about the direction things are going, not stating that DX10 will be there already.Chalnoth said:There's no way that DX10 specifies that each pixel needs its own instruction counter and whatnot. This is a hardware-specific implementation detail. I don't expect any graphics hardware to have single-pixel granularity on branches, ever.
While there are reasons to to keep granularity at quad-level or above (which are mostly related to instruction fetch/decode and thread management), texturing isn't one. DX9 doesn't allow the calculation of gradients inside branches, and I think there is no reason for D3D10 to change that. It makes no sense to take both branches for pixels just to calculate a gradient that is meaningless. Taking random gradients would be just as accurate.Chalnoth said:Regardless, though, due to the way the hardware works, there's just no realistic way to drop the granularity below the quad level (because of texturing). So 4-pixel granularity is the absolute minimum.
There will be many branching situations where the gradient will not be meaningless. Just consider a quad where two pixels are occluded by another surface. Many branches could be thought of in a similar way: you're performing one pixel shader up to some boundary, then performing some different shader.Xmas said:It makes no sense to take both branches for pixels just to calculate a gradient that is meaningless.
How do you aniso then? If you don't have information from neighbouring fragments, you can only compute derivatives analytically. Although that sounds appealing at first, you need to realize that this breaks down when you have dependent texture reads, or when you perform some computation on texture coordinates before the texture fetch.Xmas said:While there are reasons to to keep granularity at quad-level or above (which are mostly related to instruction fetch/decode and thread management), texturing isn't one.
It doesn't require anisotropic filtering. Even plain old bilinear filtering with MIP mapping requires derivative computation.Bob said:How do you aniso then?
In DX9 you simply can't calculate derivatives in a branch. If you need them, you have to calculate them beforehands for every pixel and use texldd in the branch. I guess it is possible to let the compiler automatically do this so you don't have to worry about it when you write HLSL code, but then it might happen that the savings from branching are smaller than you expect.Bob said:How do you aniso then? If you don't have information from neighbouring fragments, you can only compute derivatives analytically. Although that sounds appealing at first, you need to realize that this breaks down when you have dependent texture reads, or when you perform some computation on texture coordinates before the texture fetch.
Ah, but what about dependencies? You'd have to be careful that all calculations that go into any per-quad operation also have to be per-quad.psurge said:The idea is to expose the fact that a shader operates on a quad of "adjacent" inputs to SW, thereby punting on the HW complexity of thread communication completely, and giving programmers free reign as to how to intermix computation inside of a quad. For example, some quantities (like texture LOD) could be computed per-quad, some per pixel, and, if the appropriate output options are available, some could be computed on a sub-pixel (e.g. per sample) basis.
struct InputForOneFragment
{
int x,y, vface;
vec4 whatever;
vec4 andSoOn;
//...
};
struct OutputForOneFragment
{
bool valid;
vec4 aResult;
//...
};
OutputForOneFragment out = ShaderProgram(InputForOneFragment in);OutputForOneFragment out[N] = ShaderProgram(InputForOneFragment in[M]);Xmas said:In DX9 you simply can't calculate derivatives in a branch. If you need them, you have to calculate them beforehands for every pixel and use texldd in the branch. I guess it is possible to let the compiler automatically do this so you don't have to worry about it when you write HLSL code, but then it might happen that the savings from branching are smaller than you expect.
As long as you know the derivative of the function you're applying to the texture coordinates, you can still compute derivatives analytically.
I have to admit there's truth to that. It creates some serious implications on which branching behaviour is faster.Chalnoth said:There will be many branching situations where the gradient will not be meaningless. Just consider a quad where two pixels are occluded by another surface. Many branches could be thought of in a similar way: you're performing one pixel shader up to some boundary, then performing some different shader.
# first
if some_condition:
tempcoords = coordfunction1(coords1)
temp = sample(tempcoords)
ret = somefunction1(temp)
else:
tempcoords = coordfunction2(coords2)
temp = sample(tempcoords)
ret = somefunction2(temp)
return ret
# second
tempcoords1 = coordfunction1(coords1)
tempcoords2 = coordfunction2(coords2)
gradients1 = deriv(tempcoords1)
gradients2 = deriv(tempcoords2)
if some_condition:
temp = samplegrad(tempcoords1, gradients1)
ret = somefunction1(temp)
else:
temp = samplegrad(tempcoords2, gradients2)
ret = somefunction2(temp)
return ret
