Trying to optimize a rotation shader

[Pixelthief]

I've been working on a toughy project that calls for rotation the entire screen at runtime; a 512x512 texture (as viewed in a 362x362 box circumscribed inside). The single continuing problem thats been holding us back has been slowdown on some peoples machines- I can't get it to run a uniform 50 FPS on everyones computers. Over the past week, simple optimizations to the pixel shader have brought me up from 49 FPS to 56 FPS on my own system (an edited copy of the one sphax posted, which converts it to polar coordinates and back, as seen here):

// Pixel shader input structure
struct PS_INPUT
{
    float4 Position   : POSITION;
    float2 Texture    : TEXCOORD0;
};

// Pixel shader output structure
struct PS_OUTPUT
{
    float4 Color   : COLOR0;
};

// Global variables
sampler2D Tex0;

float fAngle;

PS_OUTPUT ps_main( in PS_INPUT In )
{
    // Output pixel
    PS_OUTPUT Out;
	In.Texture.x = In.Texture.x-0.5;
	In.Texture.y = In.Texture.y-0.5;
	fAngle =  radians(fAngle);
	float Ray = sqrt(pow(In.Texture.x,2)+pow(In.Texture.y,2));
	float Angle = acos((In.Texture.x) / Ray) * sign(In.Texture.y) + fAngle;	
        In.Texture.x = 0.5 + cos(Angle)*Ray;
        In.Texture.y = 0.5 + sin(Angle)*Ray;
   	Out.Color = tex2D(Tex0, In.Texture.xy);
	
    return Out;
}

// Effect technique
technique tech_main
{
    pass P0
    {
        // shaders
        VertexShader = NULL;
        PixelShader  = compile ps_2_0 ps_main();
    }  
}

But some people still get FPS around 25-30 on their system, which would render my game unplayable. So what I've been searching for is alternative means of doing the rotation calculations. Carrying out 512x512x50 square roots & arccosines per second is a serious load in the first place, and the inefficiency of HLSL complicates that. I've attempted the simple things like using Distance(a,b) instead of that sqrt(etc), but it still comes out the same.

Anyone know a better way to do this? I know that D3DX has matrix rotation vertex shaders built into it which should be many times more efficient (assembly code and optimized), but I don't think theres any way for MMF2 to support vertex shaders in the first place, is there? Otherwise I'm at a loss for the moment. If there is, please do tell!


Anyway, for anyone who this came off as a bunch of gibberish to, you can actually help me too- if you've got the time, just take a peek at my project and tell me what FPS you get on your machine / graphics card:
http://themofoley.googlepages.com/PlatformerHWA49fps.zip


and much thanks to sphax of course

[Anders]

Try do something like this:

float angle = //whatever angle
float2 point = { In.Texture.x - 0.5, In.Texture.y - 0.5 };
float2x2 rotationMatrix = { cos(angle), -sin(angle), sin(angle), cos(angle) };

float2 newPoint = rotationMatrix * point + {0.5, 0.5};
Out.Color = tex2D(Tex0, newPoint);

Not sure if some of this even compiles, can't remember HLSL syntax from just writing a single shader

The idea behind it explained here:
http://en.wikipedia.org/wiki/Rotation_matrix

[Pixelthief]

Oh lord, that was so simple I can't believe I didn't think of it. I mean, not exactly what you said, but a bit different. You can't really do the texture matrices in pixel shaders, because you'd have to be operating on the entire matrix of textures; thats a vertex shader's job. But what I *could* do is just multiply out the obvious rotation vectors:

Texture.X = X * Cos(A) - Y * Sin(A)
Texture.Y = Y * Cos(A) + X * Sin(A)

I can't believe that didn't occur to me.
I rewrote the body of the shader and it looks like this:

PS_OUTPUT ps_main( in PS_INPUT In )
{
    // Output pixel
    PS_OUTPUT Out;
	In.Texture.x = In.Texture.x-0.5;
	In.Texture.y = In.Texture.y-0.5;
	float Temp;
	fAngle =  radians(fAngle);
	Temp = In.Texture.x * cos(fAngle) - In.Texture.y * sin(fAngle) + 0.5;
	In.Texture.y = In.Texture.y * cos(fAngle) + In.Texture.x * sin(fAngle) + 0.5;
	In.Texture.x = Temp;
   	Out.Color = tex2D(Tex0, In.Texture.xy);
	
    return Out;
}

Bam, it was really that simple, and suddenly my game is cranking away at an amazing 100 FPS (the same as it gets with just CPU limitations via no pixel shaders). Theres literally no slowdown at all. Thanks a ton!

[Anders]

Glad I could help

Though I think you mixed something up about matrices. They are just simple arrays of numbers. They aren't associated with vertex or pixel shaders as such. I think they can be used in both for whatever use you have for them.

If matrices are allowed in pixel shaders (which I don't see why they shouldn't be) my version with the matrix would actually be faster than what you are doing
The GPU has special instructions for doing matrix/vector multiplications that are faster than doing them value by value.

[RhysD]

Woo! Great work Andos and Pixelthief!

[Pixelthief]

yeah ill put that up after I work out the changes for the new xlua version

[Dynasoft]

It should be faster still if you only calculate cos(angle) and sin(angle) once at the very start of the function. Partly because sin and cos are slow, so doing them once each instead of twice each is much faster, and partly because of a little-known optimization in the shader compiler:
The direct-x pixel shader compiler takes anything at the start of the pixel shader function that doesn't use the input from the vertex shader and sets it aside so that it is only executed once per draw call instead of once for every pixel.

[Pixelthief]

Humm neat trick there, ill add that in, thanks. Interesting little optimization, but I suppose if the pixel shader can't alter the inputs than it should work shouldn't it (although sin and cos are very very fast compared to sqrt, since unless I'm mistaken it uses a preset table of values for whole numbers, or maybe thats just my calculator)

[Anders]

Yes very neat trick
I don't know if the GPU has a fast lookup table but I doubt it. You could easily make one yourself and store it in a texture.

Buuuuuuut Dynasoft's method is pretty much the best solution

[Pixelthief]

I'd be surprised if it doesnt, I'd guess that at least 50% of all sin/cos calls to the GPU are for integers. Then again that would depend on the GPU wouldn't it. But yeah I'm just doing that store-the-cos trick, but remember its a tradeoff between processing & storage, but I doubt 2 extra floats would make a difference

edit: actually scratch that, my research is showing that they tend to just eschew the lookup tables simply because sin/cos can be done trivially fast, so theres no advantage.