OpenGL suite V2 Proposed
Standard version: 1.5
Major Change
Alexandre Gauthier (Inria/Natron), Peter Litwinowicz (RE:Vision Effects)
1) Flushing in current V1 suite is likely to be addressed via GPU utility suite. It has become not sufficient in an age where a GPU can have 24 GB of VRAM.
2) The currently suggested fallback in documentation are likely to be superseeded by a GPU utility suite fallback hand shake
3) Option to disable/enable suite in Instance Changed action is not well documented in v1.4
4) Multi-Threading (locking) is currently not addressed by V1 suite.
From Alexandre email:
"
What we were trying to achieve is multi-frame rendering by giving each frame it’s own OpenGL context (internally we have an OpenGL context pool). When a frame starts to be rendered, it locks the context to that frame and releases it when done.
The issue is: Since frames are rendered concurrently, the host could be calling contextAttached/contextDettached actions at the same time with 2 different contexts. But the spec forbids 2 subsequent calls to contextAttached without the associated contextDettached. Meaning the spec forbids multi-threaded rendering with OpenGL since a thread would just be locking the whole render.
So what we ended up to do, is:
1) Lock the call to contextAttached
2) Add the following property :
/** @brief A pointer property used to hold OpenGL context-specific data, such as texture or program IDs.
- Type - pointer X 1
- Property Set - inArgs property set of the following actions...
- ::kOfxImageEffectActionRender
- ::kOfxImageEffectActionBeginSequenceRender
- ::kOfxImageEffectActionEndSequenceRender
- ::kOfxActionOpenGLContextDetached
- outArgs property set of the following actions...
- ::kOfxActionOpenGLContextAttached
- Default - NULL
This pointer is a handle to plugin-owned data holding OpenGL context-specific data
(e.g. texture or program IDs). This is returned by the plugin when the context is first
attached, and then passed as inArgs to each render call in that context. This permits running
several parallel renders on different OpenGL contexts, but it violates the OpenFX spec, which
says:
"A host cannot call ::kOfxActionOpenGLContextAttached on the same instance
without an intervening ::kOfxActionOpenGLContextDetached. A host can have a
plugin swap OpenGL contexts by issuing a attach/detach for the first context
then another attach for the next context."
If the plugin returns NULL as outArgs of kOfxActionOpenGLContextDetached, it is supposed
to follow the OpenFX spec, and will have to be detached/attached when switching the render context.
*/
#define kNatronOfxImageEffectPropOpenGLContextData "NatronOfxImageEffectPropOpenGLContextData"
If the plug-in sets the pointer to a non NULL value, we know it can perform multi-threaded OpenGL, and then we just call concurrently the contextAttach/contextDettach actions in completely random orders.
Also it enables us to not free immediately the resources allocated in contextAttach right away after the render (by calling contextDettach) since our OpenGL contexts are pooled. We can cache these datas away.
Discussion
No comments on this change yet