Thanks for explaining all that Malcolm. Do you think using Vulkan could offer new possible options for developing any multi-GPU capabilities for TD? For instance fast texture sharing between multiple gpu’s, is that easier in Vulkan?
2 Likes
Multi-GPU support is definitely way stronger, in that addressing many GPUs has a saner API now.
I don’t think copying between GPUs is much different as the reality of the hardware transfers speed is still the main issue there.
2 Likes
This is awesome to hear. Congrats on getting far into the Vulkan version. I was imagining it might take a lot longer but sounds like lots of progress being made.
I haven’t followed Vulkan too intensely, but I’ve heard some of the benefits. One thing that peaked my interest are the translation layers, which sounds similar to what @malcolm was saying about feature parity being better between Windows/macOS. Does that mean there are some possibilities to more easily transition to other platforms in the future?
Linux being a big one folks are always asking about, but I’m even thinking about the possibility of having TouchPlayer mobile (if there are translation layers for that kind of thing) that can run really simple projects with a UI and some OSC out or similar (even heavily feature-scoped down version of TouchDesigner with a few UI comps and a few CHOPs/TOPs would be pretty amazing I think). Similar question would be about web compatibility layers. I haven’t followed webgl or webgpu much, but I’d be equally curious if similar stripped-down TouchDesigner of only a few UI comps, basic CHOPs, and some basic TOPs, could be made to playback small interfaces in the web.
4 Likes
It doesn’t help with Linux porting. Linux always had great OpenGL support so the OpenGL renderer would have ported without issue, and the Vulkan one will port without issue also.
The big cost of porting to platforms is the windowing system and I/O (mouse, sound etc.). Also the extra cost of dealing with maintaining all of those platform specific issues.
In general the graphics API isn’t a hurdle when porting between platforms for the most part (unless you are using DirectX)
4 Likes
Hi Malcolm. Other than improved performance and feature parity are there any other specific features we can look forward to?
Is it possible to give a hint as to when this might be released?
Nothing more specific yet. The first release is focusing on just getting everything working and up to speed. So the first release won’t be splashy. Aiming for the 2020.60000 series of builds though.
2 Likes
Thanks for all the info!
Regarding the loss of geometry shaders, just wanted to point to this funny tweet 
https://twitter.com/pointinpolygon/status/1270695113967181827
Would love access to geometry creation with compute/compute buffers though
(edit just realized the above tweet is more relevant for smartphones GPU, I did remember reading a few times geometry shaders performance could vary greatly on desktop as well)
2 Likes
Hi Malcom, thanks for all the detailed responses so far.
I was just wondering, since you are controlling more of the work that was previously left to the driver, could there be an opportunity there to expose some control over flushing / preloading GPU memory for TOPs?
I’ve had problems with projects that use a bunch COMPs for scenes of generative content, each containing several TOPs and sometimes render networks. The first time you point a selectTOP at the output of one of these COMPs, Touch of course has to cook everything inside and allocate GPU memory as needed, but in most cases this happens without frame drops.
The problem I often face is that by the time you select maybe the 50th scene COMP, you’ve run out of GPU memory and Touch hangs for several frames while (I’m guessing) the driver decides what to purge to make room for your new buffers.
The only technique I’ve seen to counter this issue is to change the resolution of TOPs you are finished with to 1x1 and then resize them the frame before you need them again. Could it be possible after Vulkan to better manange GPU memory with Python with something like an .unload() method in the TOP class or an .unloadChildTops() method in the COMP class?
And I might be venturing into dreamland now but how about a .preload() method for TOPs that allocates GPU memory and does all the CPU work that is common to all TOPs, but stops short of a full cook and execution of the TOP’s specific shader functions? And maybe a .preloaded attribute you could check before pointing your selectTOP at a TOP?
Thanks for the great updates Malcom. Hope I haven’t derailed the thread with my uneducated guesses and ideas!
That kind of stuff isn’t really Vulkan related and more just general programming. Adding preload() to all TOPs is possible but just requires a large rework of how TOPs cook. The memory allocation tends to be the expensive operation though so avoiding the shader process when preloading isn’t going to save you that much.
Sure, fair enough. Thanks for the explanation.
Is there a doubling down then in the hit to performance when GPU memory is already exhausted and you ask Touch to allocate new memory for some TOPs? This seems to be where things fall over for me, not surprisingly.
Is memory intelligently purged based on what is being cooked / displayed or it is it a simple FIFO situation? Is Touch handling this or the driver?
Cheers.
With OpenGL the driver handles it. With Vulkan I need to. It’s likely that kind of situation will be worse in Vulkan, at least to start, as there is a lot of logic/tech behind how the driver writers for OpenGL handle it that I’ll need to recreate from scratch.
On the subject of deferred rendering, what does this mean for the future of lighting / shading?
Specifically, I’m wondering about the 32 light comp limit per render TOP - will this still be a hard limit still for deferred? Or will it be possible to surpass this limit which will in turn make it easier to build more advanced lighting optimization systems and effects on top of the current system?
That limit goes away with deferred rendering since you accumulate lights using multiple passes internally (if you don’t have enough resources to calculate them all in one).
1 Like
Ok ya this makes sense. So, in a way this would operate similar to how the composite top operates, where if the number of inputs is over 32, the top internally via cpu, sort of “runs two passes”?
I guess then my only other question would be - what happens if a glsl shader tries to access say light 0, followed by light 50, within a for loop? If the first 32 lights are mapped to 32 available samplers, then would there be some extra cost or limitation or recompile needed if the desired light, is not already mapped to a sampler? Also maybe I’m over complicating this and missing some mechanic that helps with this sort of thing…
To zoom out a bit, my questions are all circling around the subject of Clustered Shading - an optimization / acceleration structure of sorts that makes it possible to render very large quantities of lights.
It does require having immediate access to all lights though in some sort of buffer since different sets of lights are iterated through on a pixel to pixel basis.
Trying to figure out if the new system would make it easier / more elegant to implement that than is currently possible, or if the same work around(s) would be necessary.
Vulkan (at least on Windows) allows for far more samplers in a single shader at least, so that’s much more open. I’m not sure in general about your question though, we’ll have to see once I dig into that more.
3 Likes
hi malcom and touch team
just want to ask when we can expect to see first glimpse of the vulkan port? cant wait to see and get hands on! especially since some of my clients have unreal-viruses in their heads… 
so to have access to the new world of possibilities regarding image-quality, feautures will be a major step, at least to me! 
best regards and thank you!
luka
2020.40000 became 2021.10000, so I’m still targeting Vulkan to make it into the ‘next’ build series, so hopefully 2021.30000.
7 Likes
So 3000 is the next experimental or the one after the next eperimental? But seeing 2021 in you estimate fills me with hope 
looking so much forward to this !
1 Like
hi malcom
thank you for your response!
any little tiny miny details… ?
will we have better integrated post effects, like ssr, motion blur, dof… or even raytracing?!
waiting so long, while seeing the glitter over the fence…
cant wait, as an 3d vfx veteran, im getting so exited to get better 3D pictures out of touch!
so, have an understanding for me and i guess for the rest of us! 
best regards, thanks for developing this wonderful application!
luka
Well to temper expectations, it’s a two phase process. The first part is just getting everything working in Vulkan. This should result in much higher performance and lower CPU usage when driving the GPU. I can architect GPU<->CPU workflows far nicer with Vulkan, so more work can be threaded, data can be output to devices with lower latency, and overall CPU cook times for TOPs will be lower.
Once we’re happy with the stability of that, then I can get started on fancy new features. Yes, we plan to greatly improve the rendering quality, building that on top of Vulkan.
16 Likes