Re: Interesting catch-up behaviour with GL multi-threading

• Subject: Re: Interesting catch-up behaviour with GL multi-threading
• From: John Rosasco <email@hidden>
• Date: Tue, 29 May 2007 17:42:57 -0700
• Delivered-to: email@hidden
• Delivered-to: email@hidden

On May 29, 2007, at 4:15 PM, Christopher Hunt wrote:

On 30/05/2007, at 5:05 AM, email@hidden wrote:

The buffering is essential for improved asynchronicity between the
CPU and the GPU.  It is this cache of things to work on that allows
one processor to perform work while the other is busy.

You can empty this implicit queue by flushing.

glFlush()?

yup.

If you do so
strategically, you won't see the lag and will still see the
performance benefits.  If you do so too frequently you'll effectively
serialize the MT engine and your performance gains will be mitigated.

OK.

So how about my strategy of disabling/enabling multi threading depending on what I'm doing i.e. when I start to drag (mouse down) and stop dragging (mouse up) - is that a decent strategy? It appears to work well but I'm wondering if I'm better off flushing strategically as you suggest i.e. within my drawRect and just prior to the flushBuffer call of my context.

Cheers,
-C

_______________________________________________
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

• Follow-Ups:
  • Re: Interesting catch-up behaviour with GL multi-threading
    • From: Christopher Hunt <email@hidden>

• Prev by Date: Re: Interesting catch-up behaviour with GL multi-threading
• Next by Date: Re: Interesting catch-up behaviour with GL multi-threading
• Previous by thread: Re: Interesting catch-up behaviour with GL multi-threading
• Next by thread: Re: Interesting catch-up behaviour with GL multi-threading
• Index(es):
  • Date
  • Thread