I am trying to optimise some of my rendering to get is useable on lower end machines (in my case a 2GHz i5 laptop with a GT 520M).
A quick investigation showed that the GPU isnt actually getting to 100%, but both CPU cores are. While most of this is non-rendering stuff (which I can likely make faster), I was surprised to find the piece of code below is apparently using 10% (20% of a core).
void RenderStaticTerrain() SetShadersInputLayoutConstantsEtc(); for region in regionsInView: //about 20 region->SetVertexAndIndexBuffer() for texture in regoin->UsedTextures(): //around 100 d3dContext->SetAsShaderResource(texture); d3dContext->DrawIndexed(...);
I used the Windows Performance Analyzer sample based profiling and that points at some AMD or Nvidia DLL's as being where the CPU spends its time, largely I believe within the DrawIndexed (found via QueryPerformanceCounter. The sampling results seemed to dump the dll time just in RenderStaticTerrain itself).
The textures, buffers, etc are all immutable usage so don't see anything obvious to consume CPU there like moving vertices about or anything like that.
Two idea I have which (both of which look like some work) is texture arrays and using a few very large textures containing the others. However I am not sure how viable either of those are, and if it would actually make any performance difference.
For texture arrays it seems I can have upto 2048 which is plenty. However I am not sure if the GPU is going happy with what seems to me like effectively random access via a vertex buffer field. The major problem however is it appears all the textures need to have the same size, while most of mine are in the 32x32 to 128x128 range, with some even larger ones.
Another idea was to pack them into some really big textures, but this always seems to cause problems with mip-mapping and texture filtering, since even if I repeat each textures border pixel a few times, a few mip levels down and I have one pixel in the small texture being made from pixels of unrelated textures.
Not sure what other options there are. I am still not really sure why that loop uses much CPU at all.
The current code is only D3D11 targeting D3D11 hardware, but I do plan to support older hardware and OpenGL.