Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

Frame Statistics

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 BenS1   Members   -  Reputation: 348


Posted 03 October 2012 - 04:43 AM

I know DirectX provides some basic profiling capabilities as explained in here:


However, I was wondering if there was actually a way to access more detailed stats, such as:
  • the total number of triangles drawn,
  • the total number of texels rendered
  • Percentage overdraw (Texels that are drawn and then subsequently drawn over again)
  • Total number of Vertices passed through the vertex shaders
  • Total number of Pixels passed through the pixel shader
  • etc.
I suspect the answer is that its either not possible, or that the information is available but only through hardware specific utilities or APIs.



#2 BenS1   Members   -  Reputation: 348


Posted 03 October 2012 - 04:49 AM

Ah ha, I may have found the answer.

It looks like you can perform a D3D11_QUERY_PIPELINE_STATISTICS query, which returns a D3D11_QUERY_DATA_PIPELINE_STATISTICS structure, as shown here:
  UINT64 IAVertices;
  UINT64 IAPrimitives;
  UINT64 VSInvocations;
  UINT64 GSInvocations;
  UINT64 GSPrimitives;
  UINT64 CInvocations;
  UINT64 CPrimitives;
  UINT64 PSInvocations;
  UINT64 HSInvocations;
  UINT64 DSInvocations;
  UINT64 CSInvocations;

Each member being a count of the number of times that part of the pipeline was invoked.

So that seems to give me much of what I'm after. i.e. the raw counts, but not the amount of overdraw etc.


#3 Bacterius   Crossbones+   -  Reputation: 10382


Posted 03 October 2012 - 08:08 AM

Don't you just hate it when you ask a question and find the answer just minutes later? Used to happen to me all the time, haha.

I think you can work out the amount of overdraw by looking at the number of pixel shader invocations (PSInvocations), if it's close to the number of pixels in your render target that were covered by geometry (hopefully all of them) then overdraw is about 0%, if it's much greater then you get more overdraw... Another method but which is only really useful for debugging is to maintain an overdraw buffer which you increment each pixel by one when its pixel shader gets invoked, this'll give you the exact number of pixel shader invocations per pixel and you can investigate overdraw issues. Though there's probably a better way to do this.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.


- Pessimal Algorithms and Simplexity Analysis

#4 BenS1   Members   -  Reputation: 348


Posted 03 October 2012 - 08:36 AM

Thanks Bacterius, you're right it'd be relatively simple to jsut compare the number of Pixel Shader invocations to the number of pixels on the screen to check for overdraw.

I also like your idea of an overdraw buffer for debugging\performance analysis. I'll have a think about that some more.


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.