🔒 Locked

A renderstate manager implementation

Started by IFooBar May 7, 2003 at 12:59 PM 11 replies 950+ views

Original Post

119

May 7, 2003 at 12:59 PM

I just want to ask if it''s worth controlling all the render-states and texture stage states manually. What I mean is this: Say I have a tree that holds a structure of type RENDERSTATE

  
struct RENDERSTATE
{
    D3DRENDERSTATETYPE state;
    unsigned long value;
    RENDERSTATE( const D3DRENDERSTATETYPE& st, const unsigned long& val )
    {
        state = st;
        value = val;
    }

    bool operator == ( const RENDERSTATE& rhs ) const { return state == rhs.state; }
    bool operator > ( const RENDERSTATE& rhs ) const { return state > rhs.state; }
    bool operator < ( const RENDERSTATE& rhs ) const { return state < rhs.state; }
};

Then I store all the possible renderstates that D3D supports in a tree with some default values...

  
// RenderStates is of type Tree<RENDERSTATE>.

RenderStates.InsertNode( RENDERSTATE( D3DRS_ALPHABLENDENABLE, FALSE ) );
RenderStates.InsertNode( RENDERSTATE( D3DRS_LIGHTINGENABLE, FALSE ) );
// Same for all the render states.

So now I have all my render states in a tree. Then I use the tree''s search method to find a renderstate and check if it''s value is the same as the one I want to set. If it''s the same I save a call to IDirect3DDevice::SetRenderStates(). My main concern is, will all the above be worth doing just to save on a call to SetRenderState() ? Or is there (there must be) a better way of doing this?

:::: [ Triple Buffer V2.0 ] ::::

CheeseGrater

May 7, 2003 at 1:29 PM

Why are you using a tree for this? I''d think an array or maybe a hash table would be more suited to the problem.

You could replace your O(lg n) search with a O(1) hash.

herbm

May 7, 2003 at 2:40 PM

If you want to track and eliminate redundant renderstates, perhaps the easiest and fastest way is just an array[number of renderstates] initially set to invalid values. The array will be sparse, but it won''t take up that much memory.

A bigger question is whether eliminating redundant renderstates is worth the effort.

From what I see, most apps have a lot bigger performance problems than just setting redundant states (renderstates or otherwise).

Development Lead
Windows Graphics & Gaming Technology

null_vector

May 7, 2003 at 4:09 PM

it is. especially if you''re targetting pure devices.

*sigh* as is my custom today....search the dxdev lists for a recent dicussion of this.

http://DISCUSS.MICROSOFT.COM/archives/DIRECTXDEV.html

herbm

May 7, 2003 at 6:14 PM

That''s not what I said.

What I said is that on the list of optimizations people need to worry about, redundant RS is far down the list of return-on-investment for 80% (or more) of the professional apps I see.

Development Lead
Windows Graphics & Gaming Technology

null_vector

May 7, 2003 at 8:30 PM

I wasn't disagreeing with you. If he has it and it does its job GOOD, it will help if even just a little bit.

I totally agree about this being a minimal performance issue but every little bit helps.

Oh yeah, and a hast table or array would be much more sensible in this situation as has been previously reccomended.

[edited by - null_vector on May 7, 2003 9:32:23 PM]

herbm

May 7, 2003 at 8:38 PM

Rockin

Development Lead
Windows Graphics & Gaming Technology

IFooBar

Author

119

IFooBar

May 7, 2003 at 10:16 PM

Thanks for the replys. So saving redundant renderstates is worth it then? Im still not quite clear on that.

And yes, using an array would be much more sensible

. Dunno why I didnt think of that. Thanks

:::: [ Triple Buffer V2.0 ] ::::

herbm

May 7, 2003 at 10:24 PM

It''s potentially a good thing to do, but there are probably better optimization and performance wins you can get.

Development Lead
Windows Graphics & Gaming Technology

Wreakon

May 7, 2003 at 10:57 PM

Render states are some of the slower things you can do to the video card, because it has to stop and "change" and if you have a lot of different stuff rendered in a particularly unordered manner the more different render states you use the more potential your application has to be just plain inneficient.

It''s definitely worth optimizing render states, if your application is targeted toward rendering lots of different stuff (a game), although, as the people here have gracefully been saying is that some things are slower, and they are right: For example:

-changing large textures,
-Lock & Loading vertex buffers (fruequently)

Although people shouldn''t critisize your decision to optimize the render states, perhaps they want to remind you that you should also take a look at your other potential slow-spots.

It is definitely worth otpimizing for render state changes.

-------
Homepage: http://students.washington.edu/andrey

Illumini

May 7, 2003 at 11:53 PM

I''m currently working on the core of my renderer and trying to balance all three of those things LOL

Renderstates
Texture changes
Vertex Buffer Locks/Switches

DrunkenHyena

May 8, 2003 at 12:34 AM

G''day!
The biggest benefit I''ve found with a manager to eliminate redundant calls is development related, not performance related. If I know that my redundant calls will be eliminated, in the earlier phases of development I can afford to set every single state I''m concerned about whenever it''s important. I can optimize some of it out at a later date.

With my renderstate manager, the above method incurs virtually no overhead, speeds my development and aids debugging. It also eliminates far too many ''Redundant render state'' warnings in the debug spew, which is nice.

You can grab my implementation out of my dhEngine. It uses an array, BTW.

Stay Casual,

Ken
Drunken Hyena

IFooBar

Author

119

IFooBar

May 8, 2003 at 1:40 AM

Always a pleasure to hear from you ken

I never thought of it from the development perspective, but that''s a good point.

Wreakon: I am definetly aware of the slower things. Thats why I was asking about this becuase I wasnt sure if it was worth considering like the other things were. Now I know though.

Thanks all.

:::: [ Triple Buffer V2.0 ] ::::

Topic Locked

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