🔒 Locked

Redundant renderstates

Started by CountOfMonteChristo Oct 27, 2002 at 5:18 PM 0 replies 350+ views

Original Post

Oct 27, 2002 at 5:18 PM

With many of the DX Samples, the Debug Output gets a lot of warnings from DX of redundant SetRenderStates. This is usually because for things like the CD3DFont class, a state block is set with all the important renderstates for drawing the text on the screen. Probably half of these have been set to the correct value already, since it contains things as the cull-direction and fillmode, hence the many D3D warnings in the debug output. What I''m wondering about: Do these things cost anything CPU/GPU wise? Does it slow down the app in any way to redundantly set the cullmode to ccw twelve times per frame? My first hunch would be no, since the output clearly says "Ignoring redundant setrenderstate". On the other hand, D3D thought it was important enough to let me know about it via the debug output. If it did matter, it would, for most cases, ruin the advantages of state blocks, wouldn''t it? Anyone have an idea?

S1CA

Oct 27, 2002 at 5:45 PM

1) The fact that you get the warnings shows you what D3D is up to - IT filters trivial redundant render states. The driver will sometimes provide extra redundant state filtering when two different settings for a state mean the same thing to the hardware.

2) The exception to this is when using the PURE device. The whole point about PURE is you remove as much CPU cycle burning interference AND help from D3D as possible.

3) States themselves usually don''t do anything until an actual render (Draw*Primitive etc) call. The driver then looks at the settings of all the relevent states and translates these into hardware specific settings. Sometimes multiple D3D states combine to form single parts of hardware register settings - so a single state change can require just as much driver translation as changing a whole bunch of states.

4) There is a "cost" of the call to the API, the virtual function at the COM interface, any redundancy and error checks, and finally the call down to the driver.

5) State blocks are good because the driver can "pre translate" a whole bunch of state changes with one handle. [Assuming the implementation in the driver is actually any good]

6) The redundant checker in D3D doesn''t spot silly changes:
SOMESTATE = TRUE
SOMESTATE = FALSE
SOMESTATE = TRUE
Render()

however since the states don''t mean anything until the render call, that''s ok (apart from the wasted COM calls and D3D redundancy checking).

7) It still makes sense to group what you render by blocks of state (maybe stateblocks, maybe your own scheme). Some people have reported success with taking the differences between two blocks of state in their own stateblock schemes to avoid per state checking and to catch things like double sets of the same state.

8) As always - it''s unlikely to be causing much of a noticable hit compared to things like bad buffer locking schemes etc - if it is, the chance is you''re setting state excessively anyway. You''ll never know though unless you profile - don''t spend too much time/effort on it until you have a complete system and profiling with D3D symbols in something like VTune shows a definate hit.

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.