1) sampling a texture from inside a vertex shader is not supported on VS2.0. You need at least VS3.0 to be able to do that.


2) values you write to global variables from a vertex shader are only valid for the current vertex - they do not persist. Think of the constants in a vertex shader being read only - a write to a constant is like making a temporary copy of the register for the duration of that vertex - anything you do to it doesn't affect other vertices.

The main reason for this is maintaining parallelism. Modern GPUs process multiple (e.g. 64) vertices in parallel - being able to write to a global constant would require synchronisation and serialisation which would result in lower performance.

So when you read back the value of your global variable, all you get is the original value that it contained.


3) What might work would be to write the maximum value out as part of the vertex, then implement a pixel shader which writes that value out as a colour. You could then set a small (say 1x1) render target texture to recieve this value. When you need to read the value with the CPU, you Lock() the texture and use it as necessary.


4) Expecting to read back the result of some GPU operation with the CPU is likely to cause serialisation/stalls and so lose the benefit of having a GPU unless you're very careful. If the output is a render target texture, then multi-buffering the output would help some.

Your way of calculating the maximum value is extremely inefficient. You should downsample multiple times calculating the maximum of each 4x4 or 2x2 block till you generate a 1x1 texture, containing the maximum. Reading back a 1x1 fp32 texture is simple.

Quote:Original post by S1CA
Modern GPUs process multiple (e.g. 64) vertices in parallel

Correct me if I'm wrong, but modern GPUs aren't capable of proccesing even so many pixels at once.

Quote:Original post by MePHyst0
64 sounds right to me, hence the fact that multiple vertices can be processed within a single pipe(for a GPU having 8 vertex pipes, it'll be 8 vertices per pipe , provided that the vertex shaders are really simple(=do not use large amount of registers, dynamic branching and so on))

We ain't talking about the same clock cycle, are we?

Quote:Original post by sogetsu
But my constant W and H would take any value besides pow(2, x), it seem hard to do the work by reduce the texture in your way.

And i have changed the codes to below:

float4 IfEnd() : COLOR
{
half a1;
int i, j;
float2 coord;
float maxValue = 0;

for(i = 1; i < W - 1; i++)
{
for(j = 1; j < H - 1; j++)
{
coord = float2(1.0f * i / W, 1.0f * j / H);
a1 = abs(tex2D(RTextureSampler, coord).x);
maxValue = max(a1, maxValue);
}
}

return float4(maxValue, 0, 0, 0);
}

and i use it as a pixel shader to render an 1*1 texture. Finally i get the correct value.
But now i get another problem: when the effect try to compile the .fx it take a long time and about 400M system memory.
Does the compiler try to expand all the for loops while compiling?

If your ps profile doesn't support dynamic branching than yes, it does.
I still think my way is better, just create the smallest power-of-two texture that is bigger than your source texture and put 0s in the unused space.

You can try compiling your .fx file using the command-line fxc.exe and outputting the results to HTML. Off the top of my head specifying /Fc and /Cc will do the job - but you best check the documentation.

Doing this should allow you to see the actual assembly that the compiler generates - thus you can get an idea of whether it is looping or not (etc..)

I'm also curious as to how you got a valid SM2 compile on a 100x100 texture - you've a maximum of 32 texture instructions [smile]

Anyway, I'd highly recommend you use some sort of down-sampling method. You can achieve the same results efficiently (both in code and performance) - its what most people use for retrieving the maximum luminance for an HDR image. Check out the "HDRPipeline" demo in the SDK - the code in there does this.

hth
Jack