AnsweredAssumed Answered

Big slowdown when binding a renderable cubemap as shader resource

Question asked by benualdo on Apr 22, 2014

I am encoutering a very strange issue with big renderable cubemaps with mipmaps.


I'm rendering to cubemaps with mipmaps only once, and then use them every frame (without re-rendering them). But only the fact that I am binding them every frame as shader resources is causing a big slowdown not every frame but every ~8 seconds. In my case the average frame time is 2.41 ms but the frames with the slowdown are ~250 ms.


This slowdown is measured in the m_d3d11SwapChain->Present(0,0) function. (called "swap" in the above capture file)


Now the even more strange things I noticed :
- removing the mipmaps pixel format removes this slowdown excepted with RGBA32f. (but it's not a solution I need mipmapping)
- I installed the latest beta drivers, issue is still present.
- If I change the size from 6*2048*2048 to 6*1024*1024 I cannot notice the slowdown anymore (it's "all or nothing", checked with the profiler that it is not present at all, not juste less visible).
- Even if I disable the draw calls that are using these cubemaps in shader, the issue is still present exactly the same way.
- Just removing the SetShaderResource that binds the cubemaps is also removing the occasional slowdown.
- it does not happen on the PC of my colleague that has a NVIDIA card


I really do not see what's happening, is the driver supposed to do something complicated just when binding a renderable cubemap as shader resource with mipmaps and if so any idea why I could take 250 ms instead of being unnoticable every ~200000 frames or so? (based on the slowdown occuring roughtly every 7-8 secs at 450 fps in the capture)