On today’s ACES Implementation TAC meeting there was a lot of discussion about the status of CTL as a language.
If there’s interest, I’d like to propose a meeting to discuss the topic further. Please reply to this message if you’re interested in participating so we can find a time zone appropriate date and time to throw some ideas around.
Thanks
In!
We should come up with a micro list of topics, things discussed so far that I remember:
Cheers,
Thomas
Here’s a link to a fairly long thread we started a while back.
yeah, sorry I had to leave the meeting early, let’s have a chat. I can talk about what Thomas was mentioning. Although why I had originally started ctlcc was to be able to provide these other languages from one reference, such that we don’t get version skew, and so it could be more optimally executed than just a simple interpreter.
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:
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.
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 ?
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.
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!
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
