• Advertisement

Archived

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

ignoring redundant renderstate->

This topic is 5550 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

hello Ive notices when in debug mode that i get butt loads of the message "ignoring redundant renderstate" this probably means that i''m setting states that are already set correct? how do I make sure im not setting states that are already state? I would guess Id need some sort of state manager? how do i go about it? thanks for any help
:::Al:::
[Triple Buffer V2.0] - Resource leak imminent. Memory status: Fragile

Share this post


Link to post
Share on other sites
Advertisement
quote:
Original post by alfmga
hello

Ive notices when in debug mode that i get butt loads of the message "ignoring redundant renderstate" this probably means that i''m setting states that are already set correct?

how do I make sure im not setting states that are already state? I would guess Id need some sort of state manager? how do i go about it?

thanks for any help




Yep, that''s correct: You''re setting states that are already set to that value.

You can check if a state has already been set via m_pD3DDevice->GetRenderstate(). You pass the required renderstate (i.e. D3DRS_CULLMODE) and a pointer to a DWORD variable, which will receive the current value of the renderstate. So if counter-clockwise culling is currently on, m_pD3DDevice->GetRenderState(D3DRS_CULLMODE, &dwValue); would result in dmValue receiving the value D3DCULL_CCW.

Apparently, though, redundant renderstates are not a big deal, performance-wise. Anyone who wishes to comment on that, by the way, please do.
Anyway, I''m not sure about that, but I do know that those messages really mess up your debug output, so I prefer not to get any. Good design often gets you a long way in removing unnecessary renderstates. For instance, in a highly simplified example:

render loop:
- Turn Alpha off
- render a
- turn alpha on
- render b
- turn alpha off
- render c

this would cause alpha being set to off twice, everytime you call the render function again. You could best change it to:

Once, at startup: Turn alpha off

render loop:
- render a
- turn alpha on
- render b
- turn alpha off
- render c

And your redundant SetRenderState is gone. If there''s just no way of doing this, just check if it has already been set, either via GetRenderState or a manager of your own.


Share this post


Link to post
Share on other sites
I''d like to add a question here:

According to your example, the renderstates (at least the way I understand it) remain as they were even after the scene has ended, been displayed, and then began again.

Is this correct, or was your example only for rendering multiple objects on the same frame?

Thanks .

Share this post


Link to post
Share on other sites
thanks for the reply. So since redundant renderstates are no biggy performance wise then, One would''nt have to make some kind of renderstate manager that handles all the setting of render states right?
Does directX internally check if a renderstate has already been set? if yes then if you checked yourself too, then that would make it double checking which is a waste.


:::Al:::
[Triple Buffer V2.0] - Resource leak imminent. Memory status: Fragile

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
It''s best to have a ''default'' state where all the renderstates are set to their default values (the way they are when your app starts up). Then, whenever you render something, change the renderstates needed, then change them back when you''re through rendering that object.

There IS a performance hit for redundant renderstates, as changing a renderstate is quite costly. For most renderstates, it changes a value on your video card, which requires a change to be sent across the AGP port and data going in and out causes clashes that slow down your processor. Moral of the story: only change renderstates when you need to. The same goes for changing textures, but that''s another story.

The keeping-the-default-states method of rendering has been used in many games, such as Tribes 2, where the scripts have to revert to this default state, or the game will look funky. And you might want to look into render blocks (CaptureStateBlock(), BeginStateBlock(), etc.) that allow you to get a handle to a specified state-block, allowing you to set a whole lot of states with a single call (REALLY speeds up your app). Hope this helps.

Chris
<ctoan>

Share this post


Link to post
Share on other sites
yeah thanks that did help. So the way I understand it is implementing a renderstate manager as a singleton or something would be the best option. So that the whole app uses just one.

[Edited for concept corrections]


::: Al:::
[Triple Buffer V2.0] - Resource leak imminent. Memory status: Fragile

[edited by - alfmga on December 8, 2002 3:22:10 AM]

Share this post


Link to post
Share on other sites
I''m wondering... Which would be better? A singleton renderstate manager, or a function that simply calls GetRenderState and checks if it has already been set?

The GetRenderState call every time would cause some overhead, of course, but so would a manager.

Share this post


Link to post
Share on other sites
Nice topic . Actually , using GetRenderState() each time you want to set a render state would be very expensive for large levels , 30-100 times per second , not only due to the call itself , but due to the additional if statements that you would use to check the value and act respectivelly (Correct me if i am wrong).The best approach would be to render everything in such a way , tha RenderStates calls are reduced to minimum.

Share this post


Link to post
Share on other sites
Calls to Get* are quite expensive and cause a stall in the render pipeline, so avoid them if at all possible.

A good opetion here is keep track of your renderstates, the overhead with a few if/else _should_ be alot less than the redundant renderstate. You should try your own wrapper function here, works really well

if (currentstate == requiredstate) break;
else
SetRenderState(...)

there is a great topic over on Opengl.org forums on this topic, a major contributor to the discussion is one of the driver programmers at nvidia. I know its OpenGL but the principles still apply.

How expensive are redundant state changes





Share this post


Link to post
Share on other sites
Guest Anonymous Poster
GetRenderstate is not working on a pure device, and the renderstates are not filtered on pure devices too.

You can find out this when you switch to SW Vertexprocessing or else, When your performence is higher than on a pure device you are doing something wong.
A pure device is the fastest way to render, when you are doing it right.
A manager is not the way to handle this, the right way is Batch,batch,batch so you habe no, or only a few renderstate changes.
When you are batching you have to sort by renderstate,shader,texture and Vertex and Pixelshaderconstants.
The Vertex and Pixelshaderconstants are expansive too !!!!!!!
I have do this and i have a performace plus of 400 %

Look at the nvidia tech doc, they are great !! But not easy to do, since there are many changes in the engine.

Share this post


Link to post
Share on other sites

  • Advertisement