Hello Mike,
Looking at the shark result, it seems to me that you probably have too
many threads, and are too quick to throw away a thread instead of re-using
it. Each thread should have a specific job and be the only thread in the
system doing that job. A job might be "responding to UI events such as
mouse & keyboard." Another job would be "issuing OpenGL commands". Still
another could be "run the game logic." Once started, threads should
basically keep running until the job no longer makes any sense!
(You'll want to look into thread communications, mutexes & semaphores and
such to coordinate these threads)
-- Tyson
> Send Mac-opengl mailing list submissions to
> email@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.apple.com/mailman/listinfo/mac-opengl
> or, via email, send a message with subject or body 'help' to
> email@hidden
>
> You can reach the person managing the list at
> email@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Mac-opengl digest..."
>
>
> Today's Topics:
>
> 1. Re: VBO not faster than immediate mode? (Mike)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 25 May 2008 17:50:38 +0300
> From: Mike <email@hidden>
> Subject: Re: VBO not faster than immediate mode?
> To: mac-opengl mac-opengl <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset="us-ascii"
>
> Thanks Ben,
>
> Like I mentioned I have never used shark (just recently switched to
> Mac in the first place so EVERYTHING is new to me - even OpenGL).
>
> I tried Time Profile (All Thread States) and the results are quite
> different:
>
> 31.0% 31.0% libSystem.B.dylib __semwait_signal
> 0.0% 31.0% libSystem.B.dylib _pthread_cond_wait
> 0.0% 31.0% libSystem.B.dylib pthread_cond_wait$UNIX2003
>
> 0.0% 15.5% libGLProgrammability.dylib glvmDoWork
> 0.0% 15.5% libSystem.B.dylib _pthread_start
> 0.0% 15.5% libSystem.B.dylib thread_start
>
> 0.0% 15.5% QuartzCore fe_fragment_thread
> 0.0% 15.5% libSystem.B.dylib _pthread_start
> 0.0% 15.5% libSystem.B.dylib thread_start
>
> 28.3% 28.3% libSystem.B.dylib mach_msg_trap
> 0.0% 28.3% libSystem.B.dylib mach_msg
> 0.0% 15.5% OpenGL glcDebugListener
> 0.0% 7.7% CoreFoundation CFRunLoopRunSpecific
> 0.0% 2.0% CoreGraphics _CGSGetPortStreamInline
> 0.0% 1.3% libSystem.B.dylib mach_port_get_set_status
>
> 20.4% 20.4% iParticle updateSimulation
> 11.1% 11.1% libSystem.B.dylib thread_start
> 2.8% 2.8% libSystem.B.dylib pow$fenv_access_off
> 2.3% 2.3% libSystem.B.dylib __bsdthread_create
>
>
> This with VBO's and 200k particles and approx. 45-60 fps.
>
> Well, few things are messy and I am aware of it. I have timer for
> redraws. After redraw (=update and draw VBO buffers) I simply spawn 4
> threads for calculations hoping they finish before next redraw. That
> was a quick hack but everything seems to work without garbage on screen.
>
> Anyway it seems that I am wasting also 11% for those thread spawnings
> (which I suspected) so I need to design little better system for those
> with my limited (read non-existing) threading knowledge.
>
> So what else should I read from the Shark results?
> There seems to be whopping 60% of time where something is blocking.
> Probably both; the VBO update and my kludged threading model?
>
>
> -mike
>
>
>
> Ben Supnik kirjoitti 25.5.2008 kello 16:24:
>
>> Hi Mike,
>>
>> Depends on which profile you used...if you are CPU limited and that
>> is "time profile" then yes, becaue it's telling you where CPU is
>> going.
>>
>> But often with VBOs the bottleneck is in wait time....the timed
>> profiler only counts functions when they do work, not when they
>> block. But blocking slows down your fps.
>>
>> Try "time profile (all states)" - that shows time spent in the
>> function both working AND blocking....
>>
>> Time profile can spot possible speed-ups by improving the speed of
>> code.
>>
>> Time profile (all states) can spot possible speed-ups by removing
>> blocking.
>>
>> cheers
>> Ben
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.apple.com/mailman/private/mac-opengl/attachments/20080525/9d12d77b/attachment.html
>
> ------------------------------
>
> _______________________________________________
> Mac-opengl mailing list
> email@hidden
> http://lists.apple.com/mailman/listinfo/mac-opengl
>
> End of Mac-opengl Digest, Vol 5, Issue 140
> ******************************************
>
_______________________________________________
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
