Questionable performance on GPU workstation

New user here. Basic I/O tasks like loading volumes, but also rendering models, selecting ROIs or working in the segmentation editor takes very long to complete, i.e. 10s of seconds to half a minute or more for a 1000x1000x1000px CT scan. A look into windows performance monitor suggests that 3Dslicer may not be making use of the two RTX2080Ti GPUs, but CPU only. Slicer uses the global settings (see below).

Are my expectations too high?

Other specs:
i9-9900K Octacore
64GB RAM
OS on SSD, data on HDD

Slicer does not use GPU for any operations beyond 3D rendering.
Only Volume Rendering benefits from high-end GPU.

1 Like

Few more comments:

I see you have a SSD as your OS drive. You would benefit from fast I/O operations, if you keep your datasets on SSD. When saving NRRD (or nifti) volumes, Slicer tries to compress files by default. As far as I know, compression is currently single-threaded and can be quite long for large datasets. When you are saving, you can optionally disable compression (expand Options, and uncheck compress). Here is a related post showing the impact compression may have on I/O: Can Slicer utilise multiple cores on linux? - #6 by muratmaga

Your GPU is good that you should get very nice 3D rendering performance in volume rendering. If it stutters, make sure to set the Rendering quality to “Normal” (Advanced->Techniques->Quality in Volume Rendering module).

1 Like

10-30 seconds load/save time is normal for a 1GB volume if it is compressed. If you can zip a 1GB file on your computer much faster with any software then let us know.

GPU (or many-core CPU) can only make an algorithm faster if you can split the processing to many independent tasks. Unfortunately, most algorithms are sequential in nature and you need to make significant effort to redesign them to allow running some parts of it in parallel. GPU implementations of algorithms have many disadvantages compared to CPU versions, such as they are much more complex (you can only utilize a GPU if parts of the code run concurrently, and this is always complex), not as flexible as CPU implementations (only work for certain data types, require certain graphics hardware and software capabilities, etc.), much harder to debug (no direct access to data during interactive debugging), and it takes significant amount of time to move data between GPU memory and the rest of the application (CPU memory).

In practice, for generic computational algorithms (that are not particularly easy to parallelize) you can only achieve a modest performance improvement (let’s say computation will be 2x faster overall), which is of course nice, but not worth the effort of implementing and maintaining parallel CPU/GPU implementations of large parts of the code.

We heavily utilize GPUs for rendering and other processing steps that are very close to the end of the data processing&rendering pipeline, because GPUs are well positioned to perform these steps for many reasons. The data is already in the GPU, many rendering operations are relatively easily parallelizable, you don’t need to send the results back to CPU, rendering can run in parallel with processing, rendering pipeline is relatively rigid compared to data processing pipelines, etc.

We have a infrastructure and few examples of doing other data processing on GPU. Therefore, if you identify performance bottlenecks in your workflow then you may decide to reimplement those steps and run a bit faster on GPU. However, in general, best use of your resources is to utilize the GPU for tasks that its special architecture fits well naturally.


To improve performance make sure that the input volume is cropped and downsampled to the minimum necessary size (you can use Crop volume module). If you cannot go any lower and performance is still not good enough then use a computer that has high CPU clock rate and lots of fast RAM. If that’s not feasible then you can to cut up your volume to smaller ones, edit these pieces one by one, and in the end put the pieces back together into one large volume.

1 Like

thanks everyone for the extensive replies!

I am travelling and will get back to you as soon as I have access to the workstation again, in a week or so

1 Like

I recently got back to working in 3D slicer, and I paid some more attention to performance at different steps. I think everything is performing as expected given the file sizes and the machine. loading on cropped images is MUCH faster than the whole thing, and rendering performance IS great, not stuttering or anything.

@lassoan, thanks again for taking the time to explain the nature of GPU optimization!

1 Like