Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 3 of 3

Thread: standardised GPU profiling

  1. #1
    Junior Member Regular Contributor
    Join Date
    Jan 2003
    Posts
    115

    standardised GPU profiling

    Hi,

    I wanna have a standardised GPU profiling extension. Vendor independent.
    On the CPU you can do nice profiling of your application with rdtsc but for the GPU? No chance to profile your GPU without destroying parallelism.
    It shouldn't be too hard to provide hardware/driver support for an asynchronous performance query.
    On directx you already have something like NVPerfHUD. Please provide for OpenGL a vendor independent extension to query some usefull performance data.

  2. #2
    Intern Contributor
    Join Date
    Feb 2004
    Posts
    98

    Re: standardised GPU profiling

    Qualitative analysis can already be done in the existing API, and some quantitative analysis can be done using the feedback buffer. A profile buffer extensions to the feeedback buffer has been suggested in a previous post.

  3. #3
    Junior Member Regular Contributor
    Join Date
    Jan 2003
    Posts
    115

    Re: standardised GPU profiling

    Originally posted by chemdog:
    Qualitative analysis can already be done in the existing API, and some quantitative analysis can be done using the feedback buffer. A profile buffer extensions to the feeedback buffer has been suggested in a previous post.
    what feedback buffer? Could you perhaps elaborate what you mean and how you can find the GPU Pipeline/Shader bottlenecks with that?

    Searching I have only found the "[shaders] glQueryProgramPerformance()" thread. This profiling ability shouldn't be limited to shaders but all relevant bottlenecks possible. And the main point of such a extension wouldn't be "Just getting a performance number..." but to get an idea of your hardware utilisation. Hardware and Software gets more flexible and more powerful and with that also the optimizations get more complicated.
    Yes, you can do many things with try and error, changing data, resolution and so on but this shouldn't be the case for a modern 3d api. Especially if you extrapolate to the next hw generations when you will have lots of data, lots of shaders resulting in an enormous number of combinations.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •