Archived

This topic is now archived and is closed to further replies.

A renderstate manager implementation

This topic is 5333 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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 ] ::::

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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 ] ::::

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 ] ::::

Share this post


Link to post
Share on other sites