Sign in to follow this  
lipsryme

Setting the same texture multiple times - overhead ?

Recommended Posts

I was thinking...if I were to draw 6 objects in a row.

 

And all those 6 objects use the same diffuse texture.

Would I be wasting performance setting the same texture 6 times, or can the API tell that the exact texture is already set and just ignores it ?

Edited by lipsryme

Share this post


Link to post
Share on other sites

It still costs performance.  You should monitor which state is already present in the API and then accordingly only update when it is necessary.  I just wrote a journal post on this very topic, comparing the different methods that I have used in Hieroglyph 3: Pipeline State Monitoring.

Share this post


Link to post
Share on other sites

A debug device should warn you that you're making redundant API calls. It does this by keeping track of the API state and checking if each new state-change is the same or different - but this is just debug behaviour.

 

In non-debug mode, the device has no need to do any kind of redundancy checking, because it's better to assume that the app/game is already filtering out redundant commands.

Share this post


Link to post
Share on other sites

It is highly likely that the driver will detect this and no actual sampler binding will take place; in fact this is so basic that re-binding a texture will likely cost close to nothing.

It might not cost you GPU time but it WILL cost you CPU time; due to a lack of redundant state checking on texture bindings for a while on our last game (which was targeting 60fps...) we were losing a lot of CPU time each frame due to repeatedly setting the same texture and taking a trip into the driver.
(We, of course, fixed this... and by 'we' I mean 'me'... ;))

Doing redundant work and hoping the driver will 'sort it out' isn't a good plan at all.

Share this post


Link to post
Share on other sites

A debug device should warn you that you're making redundant API calls. It does this by keeping track of the API state and checking if each new state-change is the same or different - but this is just debug behaviour.

 

In non-debug mode, the device has no need to do any kind of redundancy checking, because it's better to assume that the app/game is already filtering out redundant commands.

I don't recall seeing anything like this in D3D11 - is there a specific way to enable these warnings?

Share this post


Link to post
Share on other sites
I have never seen this behavior either on a debug device. The only way I have to see the redundant state setting is using PIX which I think is an overlooked resource.

I removed 40 additional states via pix and stepping thru a single frame.

I would love to know how to enable that via the API though

Share this post


Link to post
Share on other sites

I don't recall seeing anything like this in D3D11 - is there a specific way to enable these warnings?

In D3D9 you'd use the DirectX control panel to enable the debug device and also turn up the debug output level to max. In GL you'd use gdebugger wink.png

In the D3D10/11 section of that control panel, it allows you to mute warnings regarding "state setting", which might encompass redundant states, but I'm not sure. The message ID list doesn't seem to contain any entries for redundant calls, unless they're reported using the 'info' ID...

Maybe D3D10/11 do filter redundant states internally, or maybe they don't even filter them in debug mode?

Share this post


Link to post
Share on other sites

I suspect there is no redundant state monitoring by the D3D11 debug layer - I haven't ever masked out any messages, and I haven't seen any such messages coming through.  With the big emphasis on reducing the overhead of the API, it would be logical if they removed this and left it to PIX/Graphics Debugger functionality to find and eliminate redundant state calls.

 

In addition, even if they did it internally, it still costs some cycles to do the API call since you have to transition from user mode to kernel mode - so it is much better to monitor the state on your application side than it is to leave it to the driver and runtime.

Share this post


Link to post
Share on other sites

Some D3D11 functions like CreateBlendState explicitly mention in the documentation that they do detect redundant states for you.

That may be true for an object creation method, especially since the states themselves have a fixed number of permutations that can be created.  But if you try to set the same state 100 times, you still are effectively costing runtime every time you make the call with the same state interface pointer.  So the key to the performance questions are the Set*** calls rather than the Create*** calls.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this