" I'm using the tex2Dproj function to get a free hardware PCF filter"
I don't think that is exactly how it works. Besides, anything you do in a shader program is on the hardware, and it sure isn't free.
It does work like that (it's a D3D9 extension that every card supports nowadays), and the term is correct as the filtering is performed by the hardware and not by calculations in the shader (software).
It makes sense in some situations, like when you create a rasterizer state and name it, then somewhere else in the code you create another rasterizer state with the same values you will just get the same object from before and attempting to name it would overwrite the old name.
Yes, you should definitely implement the effect in your code. You don't need to use MSAA at all but FXAA tends to blur everything a bit and it doesn't work particularly well on UI so you might wanna use MSAA for that.
Thanks guys for your reply, but I think that rendering to a multi-sampled render target then resolving it is a MSAA rendering technique not a SSAA rendering.
It becomes a SSAA technique once you render your objects into the multisampled target with SV_SampleIndex as a pixel shader input, forcing it to run per-sample (unlike MSAA where the it runs per-pixel).
Are you sure it's the *RenderTarget change that "fixed" the bug and not the fact that you switched from D2D1_RENDER_TARGET_TYPE_DEFAULT to D2D1_RENDER_TARGET_TYPE_SOFTWARE (which doesn't use your graphics card anymore)?
Given how the order that works is the one with lightVP at the end, I think the value might be getting optimized out when you compile the pixel shader (but not when you compile the vertex shader, since it uses it) leading to a layout mismatch. I'm pretty sure the compiler is not supposed to do that so I might be wrong here.