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?
There are generally 2 reasons to un-bind a resource after you're done drawing with it:
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.
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.
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...
