Some random NVidia Nsight stats for GSB2 January 2, 2015 cliffski These DrawPrimUP calls are a pain, must find a way to reduce those… May have to do some reading to work out the significance of some of this, but draw calls is definitely too high…
DrawPrimUPs are evil, get rid of them _all_. It’s better to use a single dynamic VB you can control than to let them do something fishy in the drivers.
Yeah its kinda embarrassing to have so many, but then I have a lot of instances where I need to draw a sprite where the texture and render states of the objects before and after are different, so it’s kind of overkill to vertex-buffer copy and index just 4 verts :(
I’ve seen cases where a _single_ DrawPrimUP would mess up performance. It was years ago though, could be very different now. You can use a single VB/IB for all that stuff and just add a bit of data to it with that “no overwrite” flag (and “discard” when it’s full). It’s what DrawPrimUP does anyway to push the data to the GPU, but less efficiently. So there’s still VB copy (and likely VB allocation), just hidden from you. Also group them by states/textures as much as possible. Order for blending etc. is only relevant if the things overlap each other, which isn’t that common usually. And shameless plug – if you need some consulting for that (or similar) stuff, or maybe even some programming done, I could use some cash right now: http://ranmantaru.com/games/resume
The big issue I have is that I actually have alpha blending on virtually everything (gives me nice fuzzy edges), and there can be thousands of things on screen moving in a lot of parallax, and sorting out what is on top of what is non trivial. Combine this with the fact that every object is drawn about three times (different render targets, which then get composited into the final frame), and the opportunity to do a simple sort by X, and batch them in that sense is lower than you would expect. For example a hell of a lot of renders are multi-textured ships with a base and a top layer, which by definition stack on top of each other. Other than a run-time atlasing of those textures I don’t have an easy way to group those draws sensibly :(
Atlasing is great for grouping draw calls, and it’d make a lot of sense in your case, I think, since you have multiple ships of the same design in the battle. I do detecting what is on top of what just by bounding boxes for GUI, going through the stack of render groups and adding to the existing group when there’s no overlap, or starting a new group on top when there is. Works great, like draw all buttons in one call, then draw all text etc.
