I’ve been trying to dig my hands into the TD C++ interface for POPs with CUDA. While the provided header files are somewhat helpful, I would love to hear of any resources which sheds more light on it, and some best-practices when dealing with the exposed data structures. (Examples such as; general write-ups or public repositories with examples of custom operators, in particular for POPs)
If not, I would love to get in touch with others to untangle the CPlusPlus_Common.h spaghetti as a collaborative effort.
1 Like
Hey,
I’m happy to improve the header. Can you be more specific about where is it failing you and what would make it better for your usage case?
Hi there!
I’m away from my laptop now, but I’ll work from memory as I’ve spent the week trying to go from a minimal setup and writing some notes for myself.
Speaking of notes: let’s say I’ve collected some wisdom from playing around with it and shaped a little community documentation jump-off point, would it be within the non-commercial license to publish it to a public repository? I’m eyeballing a commercial license, but I’m holding off until I’m sure that the c++ interface gives me enough freedom and power to create what i want.
So back to the nuts and bolts of POPs:
- if I hold smart references to buffers in the custom POP class and modify them, does passing them to the output involve a copy both to the output, and to the input of the next node?
- Pop_buffer::get_data() - when copying the input buffer, I noticed a crash unless this method was called (both outside and inside the beginCida/endCuda block). Beyond returning the address to the underlying buffer, what happens here?
- It is unclear how to instantiate a new pop_InfoBuffers struct, as some of the members are wrapped inside a OP_SmartRef.
- The two lines strip info buffers are a bit confusing to me. One specifies a start index and the number of vertices, plus end of line, in pairs, which is clear. However, the purpose of the second one and the example given for it is unclear when the index buffer is already provided.
- How would I go about passing a warning or error message to the node info window? I noticed there are get warning and get error methods exposed, but no set methods. Additionally, the OP_String struct only has a default constructor exposed.
- Given What’s exposed in the header, is it feasible to set up a test environment with mocked input data without too many hoops to go through? Writing code without testing gives me anxiety.
Thats all from the top of my head, and thanks for your time!
In general, without seeing the proprietary implementation, a lot of guesswork is needed to infer what happens under the hood, as it’s not always clear from the API and the limited documentation on the derivative website
Thanks for the clarifications. Yes, you are free to post the sample code even if you have a non-commercial license.
Answers:
- It depends if you are using CUDA or CPU buffers. If you are using CUDA then there is no copy for the output, it’ll use the buffer as-is. If it’s a CPU buffer then there is a CPU→GPU transfer. For the input to the next node, its the same as any other POP→POP connection. It may be a reference to the buffer or just use as an input to the operation.
- It also depends if you are using CUDA or CPU buffers again. For CUDA it needs to setup the sync between your Vulkan command buffer that last uses the memory and your cudaStream_t. Then it gives you the CUDA address which you can use to record new CUDA commands (using your cudaStream_t). For a CPU buffer it’ll issue a download operation for the data from GPU→CPU. When you call getData() on the buffer you get back, it’ll cause a stall to occur until the download is completed.
- You can create just a default instance of that struct. Then you can use createBuffer() to allocate the info buffers you need.
- The second line strip info buffer is required to quickly determine which linestrip a given point belongs to. Without this you would need to walk backwards through the entire first info buffer to count the line strips and their sizes to determine this. This is a speed optimization that line strip require for performance reasons.
- You just need to return something from those getError/getWarning functions, and the info will show those warnings/errors.
- I’m sure it would be possible, but it would be a large task. Better to just test from within TouchDesigner.
1 Like