When I run my program with Direct3D9 debugging enabled, the debug spew gives me 12 warnings that say "Direct3D9: (WARN) :Ignoring redundant SetSamplerState Sampler: 0, State: 15" where the "State:" part on each line has 13,14,25,15,16,17,18,19,20,21,29, and 30. It appears on the line Effect->BeginPass(0). From what I've gathered in other posts, this error is due to something calling SetSamplerState and setting a certain state, though the "new" state was the same before the call. That's understandable, as that creates an unnecessary API call overhead. So what am I confused about? I'm not actually calling SetSamplerState at all! It seems that Effect->BeginPass(int) automatically calls the SetSamplerState function, as I have the following sampler in my code: I've tried removing all the sampler_state members but the texture itself and I still get the warnings. Is there something I should be doing in order to avoid this warning? Or at the very least, is there any way I can turn off the warning without turning off Direct3D debugging? All the debug spew makes the debugger go painfully slow and sometimes choke on the buffered Direct3D debug info calls.

As far as I know ID3DXEffect uses SetSamplerState, and I know that this has been brought up several times before... however I don't know anything about the solution/outcome of it... but guessing that ID3DXEffect is an independent object it might just be the way it behaves...

Someone else with a definite answer?
(Try searching the forum in the mean time and you'll likely find something)

Look at the StateManager sample that comes with the DirectX SDK. It shows how to filter out redundant state changes with the Effect interface. Note that on an "impure" device, these changes are filtered out for you by the runtime, but on a pure device, redundant state changes are not filtered for you, and can adversely affect performance.

Interesting program, but one thing I noticed is that even the SDK example is full of the "Ignoring redundant SetSamplerState" debug spew! I would have thought that a StateManager example would have fixed this...

Is there a #define that I can use at compiletime to get rid of this warning? I'd still like to be able to use the debug information regarding memory leaks and fileIO. If Microsoft's own StateManager sample can't get rid of the debug spew when using Effect files, then it doesn't seem like a very pressing issue.

Thanks guys, that cleared it. In the future though, it seems like keeping track of state changes should be a big concern, as it can cause quite a bit of overhead.