D3D11 Direct draw batching

[doitsujin]

Because @DadSchoorse bullied me into it.

This uses VK_EXT_multi_draw to batch consecutive draws with no state changes, in much the same way we already batch consecutive indirect draws into a single indirect multidraw. Even if the extension isn't supported, this may slightly reduce CPU overhead because we're no longer redundantly checking dirty states all the time.

Games that see a notable reduction in draw calls include the Atelier series, Yakuza 0 / Kiwami, Nier Automata, Watch Dogs 2.

Based on #4699 to avoid rebase hell.

[adamdmoss]

It's a cool idea and the implementation looks more straightforward than I might have supposed.

My mild and probably worrying-over-nothing concern with anything that defers real work (rather than antiwork like barriers and binding 😀) is that it increases the risk of the GPU falling idle when it could be doing something useful-albeit-suboptimally-batched. Perhaps only a real-world risk in something like a shadow pass where practically a whole scene worth of geom might be deferred; I don't see a batching limit in my cursory reading of the PR diffs.

[doitsujin]

The batching limit is implied by the CS chunk size, which is 16 kiB (which translates to up to 1022 non-indexed draws and 817 indexed draws, respectively). This really doesn't change much for our submission logic since we end up filling up CS chunks either way, and the GPU submission logic is (loosely) based on that.

[doitsujin]

Also, again, this is a relatively rare scenario in general, most of the time there will be some sort of state change going on between draws even in a shadow pass (game binds a vertex shader, changes vertex/index buffer, updates a constant buffer, you name it). It is actually uncommon for games to run into this on a regular basis.

One thing this covers though is that e.g. Atelier Sophie 2 renders particles one at a time (as in, literally Draw(4, ...) for every single particle) with different vertex offsets each time.