Jump to content

  • Log In with Google      Sign In   
  • Create Account

Setting the same texture multiple times - overhead ?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 lipsryme   Members   -  Reputation: 1021

Like
0Likes
Like

Posted 23 March 2013 - 12:45 PM

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, 23 March 2013 - 12:46 PM.


Sponsor:

#2 Jason Z   Crossbones+   -  Reputation: 5062

Like
3Likes
Like

Posted 23 March 2013 - 01:40 PM

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.



#3 irreversible   Crossbones+   -  Reputation: 1348

Like
0Likes
Like

Posted 23 March 2013 - 10:47 PM

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.

 

The surest way to know this, though, is to profile it.



#4 Hodgman   Moderators   -  Reputation: 30388

Like
3Likes
Like

Posted 24 March 2013 - 12:06 AM

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.



#5 phantom   Moderators   -  Reputation: 7279

Like
2Likes
Like

Posted 24 March 2013 - 04:11 AM

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.

#6 Jason Z   Crossbones+   -  Reputation: 5062

Like
0Likes
Like

Posted 24 March 2013 - 05:53 AM

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?



#7 NiteLordz   Members   -  Reputation: 417

Like
0Likes
Like

Posted 24 March 2013 - 06:09 AM

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
Code makes the man

#8 belfegor   Crossbones+   -  Reputation: 2616

Like
1Likes
Like

Posted 24 March 2013 - 07:06 AM

I don't know about dx11 but might be same as dx9, warnings will show if you enable some options thru dxcpl.

 

dxcpl.jpg



#9 Hodgman   Moderators   -  Reputation: 30388

Like
1Likes
Like

Posted 24 March 2013 - 07:13 AM

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?



#10 Jason Z   Crossbones+   -  Reputation: 5062

Like
0Likes
Like

Posted 24 March 2013 - 07:44 AM

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.



#11 Adam_42   Crossbones+   -  Reputation: 2508

Like
0Likes
Like

Posted 24 March 2013 - 04:06 PM

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



#12 Jason Z   Crossbones+   -  Reputation: 5062

Like
0Likes
Like

Posted 25 March 2013 - 08:34 PM

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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS