GPU - extention to pass buffers with different API

[revisionfx]

Open Effects Proposal for Standard Change

Please read the contribution guidelines first.

Standard Change Workflow

• [x] Create proposal as issue (you're doing this now!)
• [x] Tag this issue with standard change tag
• [ ] Identify subcommittee: at least one plug-in vendor, and at least one host
• [ ] Discuss the idea in this issue
• [ ] Write new or updated code and doc
• [ ] Publish updates as a pull request (ideally on a feature/PROPOSAL-NAME branch)
  • [ ] Make sure that PR references this issue number to keep them in sync
  • [ ] Discuss and review code in the PR
  • [ ] Meet all requirements below for accepting PR
• [ ] When subcommittee signs off and other members don't have any further review comments, maintainer merges PR to master which closes PR and issue

Requirements for accepting a standard change:

• [ ] Header files updated
• [ ] Documentation updated
• [ ] Release notes added
• [ ] Compatibility review completed
• [ ] Working code demonstrated with at least one host and one plugin
• [ ] At least two members sign off
• [ ] No further changes requested from membership

Summary

Describe the change succintly in one or two sentences.

Motivation

Why is this change proposed?

Problem

What problem does this proposed change solve? Be specific, concise, and clear.

Impact

Is this a new feature (no compatibility impact), a change to an existing function suite (version the suite to avoid compatibility issues), a change to an existing property, or a documentation change?

How will hosts and plugins negotiate use of this change? Show how it works when a host implements it but not plugin and vice versa.

Documentation Impact

What changes to the docs are needed for this change?

Stakeholders

Who will benefit from this proposed change? Plug-ins, hosts, or both? Specific types of hosts?

Discussion

[revisionfx]

Stub

[barretpj]

Summary

BMD's extension header file ofxImageEffectExt.h defines a set of properties which enable hosts to pass images to plugins as Cuda, Metal or OpenCL buffers, with associated stream and queue objects.

This mechanism has seen widespread adoption across plugins and hosts but is not officially part of the standard.

This issue is to get these extensions into ofxImageEffect.h or possibly a separate header, with community review largely of the comments/documentation since we cannot really change functionality.

For example there is no documentation about specific error codes (compare kOfxStatGLOutOfMemory, kOfxStatGLRenderFailed) nor of whether kOfxImagePropRowBytes has any meaning and/or should be respected.

[barretpj]

Anyone know how to rename an issue? The title is wrong because there is no GPU suite and we're not proposing one.

[revisionfx]

Anyone know how to rename an issue? The title is wrong because there is no GPU suite and we're not proposing one.

There is Edit button beside the title, tested as you can see

Also there is an FR from Autodesk to add Vulkan to that list

[revisionfx]

As mentioned in meeting, PR #64 already defines error messages without GL in name...

[barretpj]

Also there is an FR from Autodesk to add Vulkan to that list

As discussed in the TSC we'll make that (and any others) a separate issue/PR to prevent it holding up this one

[revisionfx]

Should we add runOn OpenGL to be complete? I don't see a pull request for this item

[barretpj]

Should we add runOn OpenGL to be complete?

Unclear what you mean, we have the OpenGL Render Suite for that.

I don't see a pull request for this item

I made one but it wasn't great. Gary took my commits and pushed them, see above.

[revisionfx]

I know we have a suite, I think you are saying host can decide to runOn OpenGL suite also? My note is for Image/Texture, if you run on OpenGL you can use OpenCL and Cuda interop as a plugin so it already works, distinction here is in some tools we use or not OpenGL depending on user settings, I am not clear if for some hosts to send direct OpenCL or Cuda buffers makes a difference for host... (e.g. saves something). If so, we could dynamically say NO to runOn OpenCL or Cuda (then host can decide to runOn OpenGL)... or switch to request CPU and use GPU from that if faster to internally rasterize pushing back to CPU and back to GPU...