   SamplerStage changes
  Hi!Do SamplerStage changes cost as much performance as RenderState changes? Is it advisable to keep track of the changes and only change them when needed?Thx for any information! 
  Sampler state changes are not very expensive, AFAIK.However, any state change is expensive, if you call it million times... ;  On a non-PURE device, D3D will filter out redundant setting of the main states for you. i.e. RenderState, TextureStageState and SamplerState. It''s this filtering which outputs the "Direct3D9: (WARN) :Ignoring redundant SetSamplerState" type messages when you''re using the debug runtimes.This (simple) API state filtering does cost you a few CPU cycles in calling the API unnecessarily. But not too many.On a PURE device, D3D won''t perform any of that filtering so the states go all the way to the driver so are costly.Much of the work a driver does is in "translating" from what you''ve asked for in your SetRenderState/SetTextureStageState/SetSamplerState calls into the form used by the hardware (which can look nothing like the ideal D3D model - 4 different D3D states might map to bitflags in a single hardware register for example).For this reason there isn''t a yes/no answer to "is SetSamplerState more expensive than SetRenderState" - it depends on the state, and on what other states have been set, and on what the driver has to do to turn that state into it''s hardware equivilent.Some types of states cost more to the hardware obviously - alpha blending for example.The kind of things you should be trapping (if you''re not using a PURE device) are the things D3D can''t see. For example:SetRS( D3DRS_FOGENABLE, TRUE )  ADrawPrimitive(.A.)SetRS( D3DRS_FOGENABLE, FALSE ) BDrawPrimitive(.B.)SetRS( D3DRS_FOGENABLE, TRUE )  CDrawPrimitive(.C.)SetRS( D3DRS_FOGENABLE, TRUE )  D  <--- See Note BelowDrawPrimitive(.D.)SetRS( D3DRS_FOGENABLE, FALSE ) EDrawPrimitive(.E.)  D3D won''t be able to spot the fact that state setup C is just the same as state setup A and as state setup E so won''t give you any warnings and is inefficient because the driver is likely to blindly change the state because it''s "different" to what it was.Note: D3D *will* trap state setup D because it''s the same as C and you''ll get a "redundant SetRenderState" message.So that setup should be reorganised: SetRS( D3DRS_FOGENABLE, TRUE )DrawPrimitive(.A.)DrawPrimitive(.C.)DrawPrimitive(.D.)SetRS( D3DRS_FOGENABLE, FALSE )DrawPrimitive(.B.)DrawPrimitive(.E.)The only place you can''t reorganise like that is when you need draw order to be preserved and you can''t use the Z buffer for that - an example would be for alpha blended stuff.A higher level view of state management that''s capable of re-organising/sorting the draw calls by the state they set is a much better use of your time.In a game type situation, everything to be rendered has a certain rendering "look" or style. For example "environment mapped water", "glowing", "solid and lightmapped" etc. Each of those visual looks/styles/effects usually relies on multiple states (i.e. a group of or block of states) rather than just one. So sorting your Draw*Primitive calls by state actually becomes a job of sorting based on groups of states rather than looking at individual ones.Enter: D3D State Blocks and D3DX Effects & TechniquesState Blocks let you group together a bunch of state in a way that lets you set multiple state with only one D3D call. And can (potentially) be optimised by the driver so that the expensive "translation" work only needs to happen when the state block is created.The work then becomes "sorting by state block" and "avoiding redundant state block sets"Effects & Techniques are a great way of managing this from a higher level so your code only needs to worry about sorting by abstract styles or "effects" - you end up sorting batches into "environment mapped water", "glowing", "solid and lightmapped" etc.In summary - unless you''re using a PURE device, don''t spend too much time worrying about individual states, D3D and the driver will do that for you - concentrate on the higher level, app specific stuff that they can''t possibly know. --Simon O''Connorex  -Creative AsylumProgrammer &Microsoft MVP;  Thx very much Simon for that very useful information (as always )! 