   HLSL performance slower than FFP for simple task
  Alrighty, all I want to do is to draw a textured scene with the pixels drawn using a shader. I have both approaches- the usual D3D fixed function way, and a pixel shader that is as follows:sampler2D diffuseSampler = sampler_state{    Texture = <diffuseTexture>;}void PsColor( float4 texCoord : TEXCOORD0, out float4 oColor : COLOR0 ){    oColor = tex2D( diffuseSampler, texCoord );}technique ColorShader{    pass p0    {   PixelShader = compile ps_3_0 PsColor();    }}Its from memory so it might not be totally right. The upshot is, its just one texture sample per pixel.Unfortunately when I do this, my framerate drops from 320 to 280, which isn't a showstopper but its still got me a bit worried. I'm pretty sure the difference is not a timing error either. The worst part is, its not even got any lighting calculations in yet. Its just texture sampling. Is this performance hit normal? How can the FFP do texturing with lighting faster than the shader can do texturing without lighting?I'm setting the texture by iterating through the subsets in my mesh (LPD3DXMESH) and using effect->settexture with the appropriate parameters.I apologise for just dumping code and asking for answers, but I'm really stuck here and maybe there's some little thing I've missed. Thanks!   
  Fixed function pipeline knows from the beginning what you're doing and so it can do several optimizations on rendering steps.HLSL is completely written by you and it's not easy understand your code, so, most time, it simply translates it in ASM.Optimization are done at level code, and not in level of "action" you're doing.This is the prize to pay for a completely programmable pipeline.   ;  Could be related to effects9, which has some known performance issues.   ;  You're going from 320 to 280. That's less than half a millisecond. Call me when you go from 100 to 60, which would be a drop of over 6 milliseconds.   ;  I think that DieterVW may have the right idea. Try implementing your FFP code in an effect file, and see how this affects performance.   ;  One subtle reason is that compiling for a ps.3.0 target requires that the COLOR0 be interpolated in higher than 8 bit precision.  Making that ps.2.0 or ps.1.1 might get your framerate back.   ;Quote:Original post by The RugUnfortunately when I do this, my framerate drops from 320 to 280Don't mind the mildly negative tone here, here's the GameDev.net standard stock answer to these ;) Here goes:Time and time again people come here being worried by a change, say, from 1200fps to 800fps and they think something's gone horribly wrong.Using FPS to compare performance between different hardware using the same software is OK.Using FPS to compare performance between different versions of same software is one of the biggest beginner mistakes to make. It just makes no sense. This issue keeps coming up so many times at GameDev.net, in more than a dozen threads this year alone. Here's an example of a such thread.Now, to your issue. If you're really worried about this performance hit, which as Washu said, is less than 0.5ms (1000ms/280 - 1000ms/320 ~= 0.45ms), the first thing you need to know if this is because of increased CPU or GPU contention. Do you know? Did you profile? If you don't know how to accurately profile it, see the thread I pasted, and look for other similar threads that have been brought up at Gamedev.Someone guessed that using FFP allows the GPU to go faster than using PP, since it can do an optimization step. I can play the guessing game as well: I've heard that some (if not most/all?) GPU's nowadays do FFP by simulating the FFP stages using a custom (built-in) programmable codepath. Makes sense, since it allows them to save on transistors. If so, it might actually be that using FFP is slower than using PP (since FFP makes the GPU run through a bigger generic shader program). It might be that using FFP was just faster CPU driver -wise, and since you're CPU-bound you're now seeing it. If you were heavily GPU-bound, you might've seen a performance boost from transitioning from FFP to PP. Now, this is just a guess, I don't know. And you wouldn't know either until you profile.It's been such a cliche for several years now in game development, but I'll just repeat it here again: Profile early, profile often. (at least it's way better than the idiotic Knuth quote that all idiots keep repeating)   