-
Notifications
You must be signed in to change notification settings - Fork 428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adsk Contrib - Add preliminary OSL support #1462
Adsk Contrib - Add preliminary OSL support #1462
Conversation
Signed-off-by: Patrick Hodoul <Patrick.Hodoul@autodesk.com>
The generated OSL shader currently processes pixel per pixel using the Note: The implementation can contain global variables and methods so, I've encapsulated them in the shader method itself (hoping they will be private). Below is the template of the OSL shader generated by OpenColorIO.
|
During the 2021-08-19 OSL TSC meeting, I mentioned the OSL translation status and expressed the challenges to write the unit test framework. The only examples I found were complex, and contain many useless capabilities for this context. So, @lgritz proposed some 'easier' examples to improve/complete the OSL unit test framework.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks reasonable to me.
I would love to see you not use FindOpenShadingLanguage.cmake, and instead rely on our exported OSLConfig.cmake.
I'm a little concerned about what will happen when we eventually have built-in types for color4/vector4, and I wonder if all the notation will 100% work when we switch to built-in times (for example, I would expect c4.r to work, whereas now you have to awkwardly say c4.rgb.r). Maybe we shouldn't be too concerned, because it's not going to happen especially soon. Maybe I'll just have to ensure that this notation still works. But maybe it's worth building in a little bit of logic to designate this as OSL 1.x, or at least to somehow distinguish the before/after we add the new types?
I changed the OSL enum to be Concerning the OSL syntax, I suggest to first make |
Below is the command to 'enable' the OSL translation in OCIO (using OSL from |
Signed-off-by: Patrick Hodoul <Patrick.Hodoul@autodesk.com>
Looks great @hodoulp ! |
Signed-off-by: Patrick Hodoul <Patrick.Hodoul@autodesk.com>
The last commit greatly improves the OSL unit test framework by adding extra error information in case of compilation problem and greatly simplifying how to write an OSL unit test.
|
Signed-off-by: Patrick Hodoul <Patrick.Hodoul@autodesk.com>
The last commit adds more OSL unit tests and changes the cmake variable names. Below is now the command to 'enable' the OSL translation in OCIO (using OSL from master branch): Below is the test coverage.
|
We need to merge this today to release OCIO 2.1.0 in time for VFX Reference Platform 2022. Technically our project process rules require waiting an additional 3 days to merge without a second approval from outside the contributor's organization, but under the circumstances we need to forge ahead sooner. If there are any objections, please comment by today at 5pm EST. Thank you. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per TSC and Slack discussion, approving now.
Signed-off-by: Patrick Hodoul Patrick.Hodoul@autodesk.com
The pull request provides the first step of the native implementation for the OSL translation. At the high level the translation is implemented like any other translations in OCIO in order to keep the single GPU implementation even if some GPU code changes were still needed to accommodate the OSL vs. HLSL/GLSL differences/limitations.
Refer to #1435 for some details / discussions.
That's a major milestone for OpenColorIO as it enhances potential integrations like in MaterialX environment for example (as discussed in the issue). On the other hand, the OSL library could also benefit from this work by improving color management support in some of the
transform
methods for example.The OSL translation works for all the existing ops without too many changes compare to the previous writing of the GPU algorithm. So, contributors should not be lost when jumping in the GPU code. The limitations are that the Lut 1D and 3D ops which are still not supported because of the Lut data exchange using OSL (i.e. no easy technical solution for now), and the dynamic properties which are only 'local' variables for short-term. But OSL supports input parameters to any shader types so it can be implemented at some point.
There is now a new unit test framework to support writing unit tests for the OSL translation with two basic unit tests. This framework only supports the OSL shader compilation and lake of 'easy' unit test writing for now. The idea is to slowly enhance the framework and the number of unit tests.
Lastly, the
findOpenShadingLanguage()
method only works with theOpenShadingLanguage_ROOT
cmake variable (i.e. no auto discovery). Once again, that will be improve over the time to match the other find method capabilities.This PR also does some clean-up of inconsistent usage of the GPUShaderUtils.