Hello everyone,
I was wondering how to get the amount of draw calls each frame during run time?
Is there maybe a DirectX method for that?
Thanks in advance
Hello everyone,
I was wondering how to get the amount of draw calls each frame during run time?
Is there maybe a DirectX method for that?
Thanks in advance
There actually is a thing for this, called "queries"
https://msdn.microsoft.com/en-us/library/windows/desktop/ff476515%28v=vs.85%29.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ff476191%28v=vs.85%29.aspx
You need to look at the different types of queries to see if there actually is one for draw calls though (or someone tells you that knows this for sure).
Your other options include:
- using a 3rd-party application like nsight, perfstudio, or the build-in visual studio graphics debugger, which all can show you those metrics.
- if its about an application that you write yourself, just make a wrapper for draw-calls. Instead of calling ID3D11DeviceContext::DrawXXX() in your code, you wrap this inside a custom function that also increased a counter, which is reset before each frame. This gives you the metrics you want on your side of the application.
some example code:
// render queue
Why would the runtime be burden with counting the same items you are directly submitting....meaning why would it count draw calls, when you are calling draw yourself? Hint: see Hodgman post.
Amount of draw calls isn't necessarily useful information anyway. A draw call can range from quite cheap to very expensive, depending on how much state is changed before it's made, how many vertices, whether it's indexed or not, vertex order and index order, does it involve much or little overdraw, etc.
I guess it's one of those metrics that it's nice to see, and maybe it's helpful to confirm that you're not doing unnecessary work, but otherwise you really should be aware that there's a whole load of other factors at play, some of them quite deep in the pipeline and not all of them easily surfaced through application counters.
The truth of that statement is a bit variable depending on the version of D3D being used, right? I mean, obviously for full perf coverage you always need to be tracking a lot more than just draw calls, but if you're in pre-10 this is still a fairly useful metric. There were very real bottlenecks around number of draw calls, regardless of anything else, in and before 9.
10+, I absolutely agree with it mostly being nice to see, moreso then being a useful data point for actual perf.
The truth of that statement is a bit variable depending on the version of D3D being used, right? I mean, obviously for full perf coverage you always need to be tracking a lot more than just draw calls, but if you're in pre-10 this is still a fairly useful metric. There were very real bottlenecks around number of draw calls, regardless of anything else, in and before 9.
10+, I absolutely agree with it mostly being nice to see, moreso then being a useful data point for actual perf.
9 on a WDDM driver has similar perf characteristics to 10+, so yeah, the cutoff would be 9 on XP or worse. Despite that, the core of what I wrote above remains true (i.e that there are other factors which it's still important to consider), just that the fixed overhead of each individual draw call is higher.