Sign in to follow this  
Followers 0
KaiserJohan

Unbinding resources?

2 posts in this topic

Is it good practice (readability, performance, ...) to unbind resources are usage?

 

For example:

  • In my first pass, I use 5 vertex buffers, in my second pass, I use 2 vertex buffers. Is it wise to unbind 3 now unused vertex buffer slots after the first pass, even though the InputLayout does not use them?
  • Shader resources, such as textures and constant buffers. Is there any reason to unbind them after usage, if their slots are not used in the following pass?

There are exceptions of course, such as drawing to render targets and then reading them, but more like the situations I described above. Any opinions?

Edited by KaiserJohan
0

Share this post


Link to post
Share on other sites

There are generally 2 reasons to un-bind a resource after you're done drawing with it:

 

  1. To prevent DX errors and warnings caused by having a resource simultaneously bound as an input and an output. For instance if you had a texture bound to slot 5 and then you tried to bind it as a render target, you will get an error from the debug runtime saying that there's a read/write conflict.
  2. To make it clear which resources are actually being used when using a graphical debugging tool such as PIX/VS Graphics Diagonostics/RenderDoc/etc.

 

The first one is pretty easy to handle, since you're usually not switching render targets very frequently except during post-processing. For the second one, I usually have a conditional macro that enables unbinding resources after draw calls during debug builds. 

3

Share this post


Link to post
Share on other sites
On some older APIs, it might not always be clear to the API that your "left-over" input-assembler bindings aren't actually used, so the IA ends up reading from your old buffers, even though the VS doesn't need that data, wasting a few cycles per vertex.
On any API with an IA config object (InputLayout/etc), this is no longer a concern.

While we're on this topic - does anyone do manual hazard tracking?
That is, when you have a texture bound, but then also bind it as an RT, the API will automatically unbind your texture to avoid a hazzard (and log an error/warning). Does anyone track this themselves to avoid such logging?
AFAIK, on the 'next gen'/'low level' APIs, we will have to do this work ourselves or risk undefined behavior...
4

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  
Followers 0