I'm building a deferred shader and in my current setup I'm using 3 32-bit render targets, the 3rd of which is for depth. I'm thinking now though that it's unesccesary strain on the pixel shader to be inverse transforming every pixel for every light that lights it (kind of defeats the purpose of only having to transform the geometry once)... I was thinking it might be better to use the depth RT and a fourth RT and store the pixel's world position instead. The problem is I can't really work out a good way of storing it. HalfVector2 seems to make my 9800GT crash and I've heard it has compatibility problems on other cards and performance problems on the 360. All the other 32bit options seem to be integer formats which I'm not sure would be any help.

I have a total of 64bits per pixel to play with I'm sure there must be a way to accurately store the pixel's world position, I just can't see it!

There are faster ways than using the inverse of the world view projection matrix to calculate the world position from depth.

Check out this thread on gamedev Reconstructing Position from Depth.

Thanks for that, they are some good alternatives to the inverse WVP matrix solution, but storing the world position in the gbuffer will still be much faster in both the vertex and pixel shaders. I've heard people mention that they do it I just haven't been able to get any details about what RT formats they used!

I very much doubt that storing the full world position will be faster. The big problem in deferred shading is how much memory and bandwidth you need for these huge fat framebuffers, so anything that makes these buffers smaller is a Good Thing (tm). Spending a couple of shader instructions to reconstruct a value, as opposed to transferring extra bits over the bus, will almost certainly be a performance win.

Just pointing out that of the numerous papers and presentations on deferred shading, I have yet to see a single source recommend storing a position as opposed to depth (And I find it hard to believe that it has never been tried).

 That being said, I think there was an obscure forum post somewhere where someone claimed increased performance with storing positions so it may be worth a try, but I remain skeptical.

Don't store position.  Even if you use 2 16-bit float's you're going to take up more space/bandwidth and have less precision than if you stored depth in a 32-bit texture.  If you have linear depth it's possible to reconstruct world-space or view-space position using one texture sample and one arithmetic instruction in the pixel shader.  Even using the inverse WVP isn't so bad...a matrix multiply is 4 instructions, but the extra math will probably just be used to hide the latency of sampling all the G-Buffer textures.  Either way more math will be better than more bandwidth usage, since bandwidth is bound to be tight in a deferred renderer.