stateblocks

Stateblocks hold any number of state changes you want to apply, and can be applied with a single call.

Advantages:
Easy to build a few state blocks and use them
and
Only one call to D3D, so only one set of context switches to DLL and back, and only needs the stackframe setup once.

Disadvantages:
They have to be destroyed and created for device Reset,
and
Each state is applied even if redundant. For this reason both MS and nVidia say you shouldn''t use them.

Imagine you have two effects, each of which set 20 states, but only 1 state which is different between the two effects. If you apply the first effect, draw, then apply the second effect, ALL 20 states are set. Some states have a high cost to change, and you might be incurring this cost many times over when you don''t actually need to change the state at all.

If you manage your own states, and create your own stateblock like system, you can ignore states that are set to the same value. You can have states that default if not contained in a set. You''re pretty much free to do whatever you want in terms of functionality, and can avoid the performance pitfall of stateblocks.

WOW, this information is very usefull. Thanks for the last part Namethatnobodyelsetook!!

Here''s a bit more (albeit slightly old) info about state blocks:

http://tomsdxfaq.blogspot.com/2002_07_01_tomsdxfaq_archive.html#78505386

-Mezz

PS:
In what docs do MS/nVidia say you shouldn''t use state blocks?

thx for your response

quote:

---

Original post by Namethatnobodyelsetook
Each state is applied even if redundant. For this reason both MS and nVidia say you shouldn''t use them.

---

This applies for pure devices only, right? Doesn''t D3D otherwise weed out redundant state changes before sending them to the card? I''ve implemented state blocks in my own app, and saw a slight performance increase, but I''m not using a pure device.

quote:

---

Original post by chdennis

quote:

---

Original post by Namethatnobodyelsetook
Each state is applied even if redundant. For this reason both MS and nVidia say you shouldn''t use them.

---

This applies for pure devices only, right? Doesn''t D3D otherwise weed out redundant state changes before sending them to the card?

---

That would be the most logical thing, but I honestly don''t know. I think I read about MS and nVidia not liking stateblocks on the XBox developer news groups... just did a search through xds.graphics, and there''s definately people being told by MS not to use stateblocks. I don''t remember where I saw nVidia saying it... I tried searching with google, came up empty.

Whether it applies to PC, I don''t know, but since the XBox is more likely to know it''s current state than a PC, I''d wager it''s still important on the PC.

Oh, and during that google search I came up with a nice DX9 paper here, which says does say to avoid redundant states, but doesn''t say anything about pure vs. non-pure devices.

Yeah avoiding redundant states is always going to be a good thing, so is avoiding checks and lots of API calls too. I''ve found using stateblocks (on the PC, I don''t use them on Xbox) to be easy and fast. D3DX Effects also use them internally I believe, and for good drivers that handle them well there doesn''t seem a lot of benefit to the roll your own solution any more.

-Mezz