Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Poor performances when using hierarchies of renderers

Hi,

I've spent more time on this. I am not sure how to tackle the issue, and could use some further insight.

In OpenGL Driver Monitor, we do see a number of things that seem to go wrong, 
- we see a large number of OpenGL contexts (> 150). Is that bad ? It seems that whenever we call [[QCRenderer alloc] initWithOpenGLContext:openGLContext pixelFormat:format file:QTZPath] it increments the number of OpenGL contexts by at least 1, sometimes 4. Is that expected ? It confuses me a bit as we pass the same OpenGL context around. FYI, we have about 30 QCRenderers in our test.
- we see large waiting times (CPU Wait for GPU ).
- Video ram goes down quite quickly in that exemple. Has the number of OpenGL contexts anything to do with it ?

We then tried to reduce the number of QCRenderers (to about 9) by recycling them. What we see is:
- number of OpenGL contexts goes down (from 150 to 32) 
- CPU Wait for GPU goes down 
- VideoRam is luch better
- but performance is bad, since the fact of recycling the QCRenderers now requires to pass all input parameters (including images) for each frame that we compute. This just kills us.

How can we workaround that problem ?
Is there a way to prevent QCRenderers to create lots of ressources ?
If we recycle our QCRenderers, what is the best way to pass images to them (best performances ) ? I need to add  that these input images are static...so passing them at each loop seems quite a waste. We've looked at the TechNote, but are not entirely sure how to minimize the cost of passing these images representations to the compositions. Our initial tests with NSImage and CIImage were not satisfactory.

It is quite frustrating because the end result plays quite slowly (5fps) despite of being quite a simple rendering task. When we assemble all our small QC compositions into one big one that produces the same output, it plays without problem at 50-60fps...but we cannot go that route and really need to split it in smaller parts.

Thanks a lot.

Matthieu


On 18 May 2006, at 20:03, Pierre-Olivier Latour wrote:

You might be using too much VRAM at which point, data starts being paged-out / paged-in from VRAM, which is pretty slow

In general you want to:
1) use a single CVOpenGLBufferPool
2) use two GL contexts (one for the display on screen and the other one for drawing to the CVOpenGLBuffers)
3) draw into a CVOpenGLBuffer using this sequence: attach GL context, call QCRenderer, flush, detach
4) OpenGL Driver Monitor in Performance Tools is the app you want to monitor VRAM and what the GPU does



________________________________________________________
Pierre-Olivier Latour                            email@hidden
Quartz Composer Team Apple Computer, Inc.




 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/email@hidden

This email sent to email@hidden
References: 
 >Poor performances when using hierarchies of renderers (From: Matthieu Kopp|Aquafadas Software <email@hidden>)
 >Re: Poor performances when using hierarchies of renderers (From: Pierre-Olivier Latour <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.