Repository navigation
GPU - extention to pass buffers with different API #98
Description
Activity
Stub
Summary
BMD's extension header file
ofxImageEffectExt.hdefines 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.hor 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 whetherkOfxImagePropRowByteshas any meaning and/or should be respected.Anyone know how to rename an issue? The title is wrong because there is no GPU suite and we're not proposing one.
- changed the title
[-]GPU suite extention[/-][+]GPU - extentition to pass buffers with different API[/+]on Nov 8, 2022 - changed the title
[-]GPU - extentition to pass buffers with different API[/-][+]GPU - extention to pass buffers with different API[/+]on Nov 8, 2022 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
As mentioned in meeting, PR #64 already defines error messages without GL in name...
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
- linked a pull request that will close this issueChanges for issue #98 (Cuda/Metal/OpenCL properties) #101
on Nov 15, 2022 Should we add runOn OpenGL to be complete?
I don't see a pull request for this itemShould 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.
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...
Open Effects Proposal for Standard Change
Please read the contribution guidelines first.
Standard Change Workflow
standard changetagfeature/PROPOSAL-NAMEbranch)maintainer merges PR to master which closes PR and issue
Requirements for accepting a standard change:
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