I’m working with Alembic In POP and I’m confused about the GPU/CPU behavior. According to the documentation, POP operators should work on GPU, but I’m seeing CPU usage in my setup.
My setup:
Alembic In POP loading a cached sequence (~61,850 points)
RTX 3090 with latest drivers
TouchDesigner 2025 31760
The issue: When I check the info DAT, I see:
Point Count Info on CPU
Topology Info on CPU
CPU Cook Time: 0.653 ms
GPU Cook Time: 0.000 ms
My understanding was: When using Alembic In POP (not SOP), the entire sequence should load to GPU memory and play back from there, avoiding CPU↔GPU transfers each frame.
I’m trying to optimize for real-time playback of large point clouds with GPU-based particle effects. Any guidance would be appreciated!
Those entries are just for tiny bits of data that help describe the topology of the geometry. Performance is actually better when they are on the CPU, because we can dispatch operations more efficiently. They only end up on the GPU for cases where the CPU can’t know the results after a GPU operation, such as a Delete POP.
The actual geometric data is loaded onto the GPU. However there are likely performance improvements still possible with the Alembic In POP regarding this in general
I compared cook times between Alembic SOP and Alembic In POP using identical data:
Results:
Alembic SOP: ~6 ms CPU
Alembic In POP: ~6 ms CPU
Practically no difference in loading speed. This is even visible in the operator snippets examples.
Is it possible to achieve alembic animation playback without any CPU load at all?
What’s the advantage of Alembic In POP then, if loading the file itself takes the same amount of CPU time? Or is the performance gain only in subsequent POP operations, not in the data loading itself?
There will always be significant CPU load involved, since 95% of the work involved in loading an alembic file is reading the data off of the SSD/HDD drive and getting it into CPU memory. From there it’s converted to either SOP data on the CPU for a SOP, or uploaded to the GPU for POPs. There isn’t anything the GPU can do to speed up this node, since there really isn’t any GPU work to be done. The performance from the GPU gains are from subsequent POPs.
We are however working on threading this node though, so much of the data will be pre-read to CPU memory before it’s needed, which will greatly reduce it’s cook time if the file is being played back in-order.
@malcolm
Hello.
In addition to the slow CPU cook issue, it seems there’s another problem: custom attributes that can be read in the SOP version cannot be read in the POP version.
I was planning to report both issues, but since I found this topic, I’m posting it here.
I suppose what you mean is that pivot[3] has incorrect values when imported on the Alembic In POP; that will be fixed in the next official build we release: 2025.31890+.
Regarding the cook times: as Malcolm mentioned we’re actively working on some ways to improve that.
