Dear Samuel
The graphic system works as a pipeline. Pipeline steps wait for the output
of the previous pipeline steps. To make things more complicated, the graphic
system uses a lot of caches and buffers. When using OpenGL, measuring the
time it takes for an OpenGL function to return usually measures the time it
took it to put its data into the pipeline buffers (which is usually not the
measure that you are looking for).
The pipeline runs only as fast as its slowest stage. This stage is usually
called "the pipeline bottleneck". Improving the performance of an OpenGL
based application requites locating the stage which acts as the pipeline
bottleneck and then reducing the work performed in this stage.
For example, if the pipeline bottleneck is fragment processing, a developer
can improve his application's performance by using a simpler shaders.
I would recommend locating the performance bottleneck using gDEBugger Mac,
which is an OpenGL debugger, profiler and memory analyzer. It's performance
graph view and performance analysis toolbar enable's tracking, easily, the
pipeline's stage which acts as the performance bottleneck.
More information about gDEBugger Mac's profiling abilities can be located
under:
http://www.gremedy.com/webhelp/index.html?article_optimize_your_application_
performance.htm
http://www.gremedy.com/webhelp/index.html?views_performance_graph_view.htmhttp://www.gremedy.com/webhelp/index.html?toolbars_performance_analysis_tool
bar.htm
A download link, including 7 fully functional trial days, is:
http://www.gremedy.com/downloadMac.php
I would recommend starting by:
a. Switching to Profile Mode
b. Looking at the following performance counter values while your
application is profiled in gDEBugger:
- Context X - frame per second
- CPUs Average Utilization
- CPU Wait for GPU
- GPU Core Utilization %
This should give you a rough hint for the pipeline buttlenck location (CPU
or GPU).
c. Using the Performance Analysis toolbar to disable different pipleline
stages.
If performance improves after turning off a certain stage, you have found
a graphic pipeline bottleneck.
Good luck,
Yaki
-----Original Message-----
From: mac-opengl-bounces+macopengl=email@hidden
[mailto:mac-opengl-bounces+macopengl=email@hidden] On Behalf
Of Space Ship Traveller
Sent: Thursday, May 21, 2009 5:48 AM
To: Mac OpenGL List
Subject: Re: Triangle performance problem
On 21/05/2009, at 1:38 PM, Richard Schreyer wrote:
>
> On May 20, 2009, at 9:06 AM, Space Ship Traveller wrote:
>
>> Hi Paul,
>>
>> I removed glBegin, it was in some virtualization debug code, which
>> I've updated to use glDrawArrays.
>>
>> I also made it so the app is constantly drawing 6000 of the
>> triangles, so that we can see a good sample of the worst case
>> scenario.
>>
>> Here is an example. It said my app was in OpenGL 48% of the time:
>>
>> GL Function # of Calls Total Time (µsec) Avg Time
(µsec) % GL Time
>> % App Time
>> CGLFlushDrawable 2,364 26741655 11312.04
82.81 39.54
>> glDrawArrays 7,988 3825748 478.94
11.85 5.66
>> glDrawElements 11,339 550065
48.51 1.70 0.81
>> glTexSubImage2D 2,007 461869
230.13 1.43 0.68
>> glClear 2,364 239508
101.31 0.74 0.35
>> glPopAttrib 18,460 126857 6.87
0.39 0.19
>> glPopClientAttrib 16,096 112162 6.97
0.35 0.17
>> glPushAttrib 18,460 85439 4.63
0.26 0.13
>> glTexParameteri 48,299 16946 0.35
0.05 0.03
>> glTexImage2D 7 13480 1925.73
0.04 0.02
>> glColor3fv 59 13089 221.86
0.04 0.02
>> glPushClientAttrib 16,096 13087 0.81
0.04 0.02
>> glEnableClientState 47,652 9859 0.21
0.03 0.01
>> glEnable 36,173 8866 0.25
0.03 0.01
>> glDisable 26,462 8320 0.31
0.03 0.01
>
> Usually, the advice to use larger draw batches is to reduce CPU
> usage in the driver, more than improve performance of the GPU. Most
> of your time is in CGLFlushDrawable, which basically means you're
> waiting on the GPU?
>
> Can you estimate how large your triangles are (in screen pixels)?
> Are you using multisampling? If the total number of covered pixels
> are large enough, then the bottleneck will be filling pixels, even
> if you're producing those pixels with a small number of triangles.
>
I was using multi-sampling, but I've just turned it off but didn't
notice much difference in performance - it still seemed to have the
same problems. I also turned off blending. This also didn't improve
things much. There are about 6000 triangles representing 3000 quads.
They have a single texture. They are about 60px by 60px on the screen.
Any other ideas?
I'll do some more testing, but I have to go to work now unfortunately.
Thanks for your reply.
Samuel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
This email sent to email@hidden
