Skip to content

Guidelines needed for gpu running interfaces #3726

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mauriliogenovese opened this issue May 6, 2025 · 0 comments
Open

Guidelines needed for gpu running interfaces #3726

mauriliogenovese opened this issue May 6, 2025 · 0 comments

Comments

@mauriliogenovese
Copy link
Contributor

mauriliogenovese commented May 6, 2025

I am trying to update some fsl interfaces to implement support for gpu multiproc queue (#3722 #3721) and I plan to implement interfaces for some new freesuerfer cuda capable commands (easyreg, synth_strip, etc).
I don't know if and how handle the detection of a cuda capable system.

There are some premise:

  1. Some tools automatically run on cpu (eg fsl probtrackx2 or bedpostx) and have a gpu counterpart (probtrackx2_gpu and bedpostx_gpu)
  2. Some tools try to automatically run on GPU if available (eg new version of fsl eddy or fs mri_synthseg) and the user need actively switch to cpu execution if they will, either using an alternative command (eddy_mp/eddy_cpu) or a parameter (mri_synthseg --cpu)
  3. Some commands can be parallelized with their cpu version but can/should not in their gpu version

How should we implement interfaces in nipype? Always use CPU unless stated by the user or let each tool "choose" his way and intercept it to select the right cpu/gpu queue in multiproc plugin?

And another question: should each nipype dev check the presence of a cuda capable system to generate the correct workflow or do we want that devs can just set use_gpu=True and the interfaces will automatically switch to cpu it if the end-user has a cuda-less system?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant