I’m interested.
I’m trying to reimplement the new SSTS Output Transforms as Pure Nuke nodes at the moment.
Somehow I’m finding the CTL ever harder to follow than last time around.
Here is the content of the chat on the subject from last night, if it’s useful (extension changed to .ctl, as ACES Central won’t accept an upload of .txt!):
TAC_chat.ctl (2.2 KB)
Interested in following the discussions along.
A few things I was wondering:
- Pro and cons of the CTL -> GLSL -> SPIR-V -> LLVM IR worflow vs. CTL -> LLVM IR
- Thomas mentioned a CTL LLVM JIT experiment
- What about the CTL standard library that’s not implemented in CTL
The question, I suppose, is what are we looking to get out of CTL?
As it stands, it seems it is perfectly adequate for the purpose of being a simple human readable expression of the mathematical definition of a transform, with ctlrender as a self-contained executable to pass an image through as ground truth for comparison with another implementation of the same transform. The only thing I think would be a useful addition for that purpose would be another utility, similar to ctlrender (or maybe just an argument to it) that would process a single set of RGB or RGBA values through the transform, for testing purposes.
But it sounds like people may be looking for a production usable version of ctlrender that can be used to batch process images through a transform. The current version is not really fast enough for that, particularly if dealing with 4k or 8k plates, which weren’t really common when CTL was conceived. Is there a desire to use CTL in that way?
Nick, I tweaked the settings so .txt attachments are allowed.
Hi Simon from Pomfort here,
we would also be interested in further developing the tooling around CTL.
One obvious goal from our side would be to execute the ACES IDTs and ODTs in real time on the GPU for live grading. ctlrender is of no use to us in this case, as it is running on the CPU (and therefore too slow for us) and it is impossible to integrate it with our color processing pipeline that is running on the GPU (implemented with Apple’s CoreImage framework).
We would especially be interested in a CTL to GLSL transpiler, especially one that is compatible with the CoreImage Kernel language (which would exclude the support for loops). Or one that does transpile to Apple’s Metal Shader Language.
A transpiler that translates to SPIR-V would be less helpful for us - though it might be possible to compile that to Metal by using SPIRV-Cross (see https://github.com/KhronosGroup/SPIRV-Cross)
From my experience, I would advice not to use LLVM IR. LLVM IR is very much an internal representation for LLVM and its subprojects. You can’t really expect it to work with future LLVM versions and it is very loosely defined. Basically the whole reason for leaving SPIR behind (which was based on LLVM-IR) and developing SPIR-V was that LLVM IR is rather cumbersome to use outside of LLVM. So if we want to go with an existing intermediate representation, I would suggest going with SPIR-V.
5 Likes
Thanks for your inputs Simon, just by curiosity, you wouldn’t trust using LLVM codegen library to generate the LLVM IR and using https://github.com/KhronosGroup/SPIRV-LLVM-Translator to dump the SPIR-V ?
- July 23, 2020, 1PM PDT
- July 24, 2020, 1PM PDT
- July 27, 2020, 1PM PDT
- July 30, 2020, 1PM PDT
- July 31, 2020, 1PM PDT
0 voters
Just looking at the time zones of those who have expected interest, it looks like 1PM PDT is probably the best time for a conference call. Please vote for dates that work for you. No promises that the most popular choice wins as there’s a few people we clearly want to make sure are on call.
Hi Remi,
looking at the bottom of the SPIRV-LLVM-Translator README under Branching Strategy, the SPIRV-LLVM-Translator itself seems to have to keep up-to-date with the current LLVM release and you have to use a certain version of SPIRV-LLVM-Translator to compile a certain version of LLVM-IR.
I would like to avoid the scenario where a hypothetical ctl-to-llvm tool would need an old SPIRV-LLVM version that is compatible with ctl-to-llvm’s version of LLVM IR. From my experience (admittedly that is based on a master thesis 6 years ago), LLVM IR is a moving target (it’s just meant as an intermediate representation for compilers, not as an exchange format between different tools - that’s the problem SPIR ran into and that’s why we got SPIR-V).
See the “Why SPIR-V” presentation from https://www.duskborn.com/wp-content/uploads/2015/04/WhySPIR-V-Notes.pdf and LLVM’s backwards compatibility policy http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
Also, the less tools I need to get to what I need (Metal Shader Language), the better, I would say.
LLVM IR would be ctl-to-llvm, SPIRV-LLVM-Translator, SPIRV-Cross.
SPIR-V would be ctl-to-spirv, SPIRV-Cross.
I mean, if I could have my wish, there would be an ctl-to-metalshader tool, that I could use to compile CTLs to the Metal Shader that I need, without dependencies on big libraries like LLVM.
But I think, as there are other people who need SPIR-V or HLSL on other platforms, SPIR-V might be a good compromise as a target, as we basically get the rest thanks to SPIRV-Cross. The only thing we would not get with SPIRV-Cross is CUDA, at least I could not find a way to convert SPIR-V into CUDA code.
But this is all just my opinion from my perspective.
1 Like
The largest developer userbases are those of Unreal Engine and Unity and they dwarf anything else by orders of magnitude 
Going for SPIR-V and/or HLSL would certainly be an option that makes life much easier for us.
Metal at this stage is small fish in a rather large tank as far as ACES goes. Nothing against it but the walls of Apple’s Garden are higher and higher in an orthogonal way to the Open Source spirit and mantra of ACES.
Cheers,
Thomas
Thanks again for the feedback Simon !
Agree with your points, on the other side, LLVM IR (as a transient / intermediate step) seemed like an elegant way (for my novice eye!) of having both CPU and GPU implementations on par for “free” (at least theoretically).
SPIR-V can be transpiled/translated to ISPC with SPIR-V-Cross, so technically, you could go GPU and CPU with it!
1 Like
SPIRV would be fine - you can easily get to Metal via SPIRV-Cross.
@Thomas_Mansencal , you surely know about Apple’s open source contributions, including Swift, WebKit, clang, and major funding of LLVM, just to mention a few.
Sure Greg…
I’m writing that on a macbook and been running on macOS for over a decade and this screengrab has been done and augmented with Preview
@Thomas_Mansencal, Apple doesn’t maintain every open source library it has contributed or helped fund. You can of course point to a number of repositories, but that number has no actionable meaning.
Of course it does! Microsoft, Google, RedHat and Intel have simply more developers contributing to OSS than Apple. Microsoft has been the largest OSS contributor in the world for a few years now anyway. Happy to take the debate privately because this is not the place for it
No need for further debate - it’s all pedantic anyway! ACES does not discriminate - it wants to be used by everything and everyone.
I think SPIRV or some other meta language that can be easily translated to popular shader languages is the best way forward. The big issue is that ACES is growing, and if CTL becomes more popular as a result, we are really going to need a way for all developers to easily and correctly translate CTL into their preferred graphics framework.
It is worth considering that relying on a third party tool with an uncertain future like SPIRV-Cross could end up backfiring, but I’m not aware of any alternatives.
Anyway back on the topic, Microsoft maintains ShaderConductor that converts HLSL to DXIL and SPIR-V (via SPIR-V-Cross):
SPIR-V-Cross is actively developed and maintained. I’m curious as what makes you think its future is uncertain? If anything its future looks brighter than that of CTL!
Hi,
@Thomas_Mansencal just pointed me to this thead. I’ve been playing with my own implementation of a CTL interpreter in the hopes of integrating it with OpenColorIO and our upcoming OpenColorMath library.
At the moment I have a bytecode VM in C with no external dependencies, an interactive REPL, and some rudimentry support for JIT compiling directly to native x64. I also plan to emit GLSL.
My motivations for re-implementing CTL were to remove some dependency requirements of the current implementation (eg, IlmBase), provide C linkage, and as a bit of a personal challenge.
I’d love to be a part of any future discussions, and hope to have something to show soon.
5 Likes
Hi Mark,
Thanks for your first post and welcome!
Steve T
ACESCentral Admin