TUM - Computer Aided Medical Procedures Use Case

[MatthiasKillat]

TUM - Computer Aided Medical Procedures

Discussed in https://github.com/eclipse-iceoryx/iceoryx/wiki/2021-11-25-Eclipse-iceoryx-developer-meetup

Copied from the notes:

Use-case - Data-flow Processing System TUM (Computer Aided Medical Procedures)

• zero-copy for the whole processing pipeline
• async inputs from cameras
• performs image and geometry processing
• every output port is a ringbuffer
• CUDA is used heavily to perform computation
• scheduling between threads is carried out in different ways
  • currently best-effort with dropping of frames
  • fusing happens according to (approximately) matching timestamps
• limitations due to iceoryx not being aware of CUDA memory on GPU
• with iceoryx this is run as multiple processes instead of one monolithic application
• uses multiple servers over network
  • each one uses iceoryx
  • data capturing and time synchronization
  • viewer
  • computation
  • rudp for network
  • 700ms from capture to display (<1s)
• constant chunk sizes are sufficient since image sizes and related data are constant
• number of cameras can change (more is usually better but requires more memory)
• memory static - memory is acquired at the start and does not increase
  • worst case assumption or make algorithm not exceed memory for algorithm output
• conflicting use cases
  • real-time best-effort - regular publish-subscribe (drops data depending on queue size)
  • slow down to be able to - process everything (could be done by blocking publisher)
• uses iceoryx 1.0.1
• one user launches multiple docker containers

Potential of iceoryx extension for TUM use-case

• device memory on GPU/CUDA - already planned (but no time schedule yet)
• dedicated memory segments for different purposes and potentially on different devices
• configure a publisher to use a specific memory pool by name (e.g user names)
• different memory pools can associated with e.g. NUMA core
• full windows support (only nice to have, due to windows based front-end)

Further discussion is welcome, e.g. about (but not limited to) the following topics

• separate meeting to discuss the code (TUM application and iceoryx)
• discuss iceoryx API usage
• further feature requests - what would help?
• performance data
• ...

[MatthiasKillat]

@ulricheck We can continue the discussion here. I would be interested in seeing the system (overall architectural view and also how iceoryx is used in the code). If this is available in Github let me know.

@elBoberido FYI

[ulricheck]

@MatthiasKillat thanks again for the nice discussion today - I'll try to create some architectural overview that specifically addresses the integration of iceoryx in our system. In order to get access to the code-base or fragments thereof, we should probably discuss this offline (you can reach me through my university email: https://www.in.tum.de/campar/members/ulrich-eck/).

[elBoberido]

@MatthiasKillat thanks

cc @budrus @elfenpiff

[gpalmer-latai]

Checking up on this. What is the current status of GPU / CUDA memory support in Iceoryx? What work would need to be done?

[gpalmer-latai]

I have a potentially simpler use case - due to the memory architecture of the system is suffices for me to determine where the existing allocated memory is and call cudaHostRegister(&mem_pool, mem_pool_size) once per process.

At a quick glance, it seems like I can "cheat" by just taking the address of any ol' chunk and querying the pointer repository for the base pointer of that memory pool. Though currently the size of the pool is not exposed by the pointer repository.

[elBoberido]

@gpalmer-latai right, there is currently no API for this and the pointer repository manages whole shared memory segments. For you it might be sufficient to just get the address and size of one mempool. I don't think that would be too hard to add, at least not for a proof of concept. I would need to have a closer look in order to check how difficult it would be to add it in a clean way.

If you just want to do a proof of concept, you could even get the shared memory mapping from /proc/<pid>/maps