View Issue Details

IDProjectCategoryView StatusLast Update
0004496Slicer4Core: Renderingpublic2018-09-18 13:19
ReporterlassoanAssigned Tojcfr 
Status resolvedResolutionfixed 
Product VersionSlicer 4.9.0 
Target VersionSlicer 4.9.0Fixed in Version 
Summary0004496: VTK OpenGL2 Backend: Reslicing speed can be very slow on Windows

Reslicing speed can be very slow on Windows. This causes very noticeable delay when moving the slice position slider or moving slices using Shift+MouseMove.

"Performance tests" module's "Reslicing" test with MRHead data set reports 50FPS in ideal cases, but it often goes down to as low as 5-10FPS. Profilers report that more than half of the time is spent in NVidia dlls.

With OpenGL backend/Qt4/VTK7.1 the maximum frame rate is slightly higher (60FPS) and serious slowdown happens quite rarely.



related to 0004423 resolvedlassoan VTK OpenGL2 Backend: Slow slice scrolling if volume rendering is enabled 
has duplicate 0004481 resolvedjcfr OpenGL2: Reslice is 4x slower 




2018-01-17 16:16

developer   ~0015479

Disabling "Threaded optimization" in NVidia settings seems to mostly solve the problem: speed is consistently around 50 FPS.
"Threaded optimization" is enabled on Windows by default.

I've tried to find what "Threaded optimization" does and it seems that it should increase performance, unless an application "heavily rely on synchronous OpenGL calls". Probably the issue is in how VTK Qt render window works, and maybe how Slicer creates and updates multiple render windows.


There are a number of things your application could be doing that could be defeating the benefit of the threaded optimizations. The big one is calling glGetError(), but in generally any sort of glGet* call will cause a synchronization point between the threads. The other common source of slowdowns is calling functions that return data, such as glReadPixels or glMapBuffer. If you can avoid those, you are likely to speed up your application even when threaded optimizations are disabled.
Aaron Plattner
NVIDIA Linux Graphics

The NVIDIA OpenGL driver supports offloading its CPU computation to a worker thread. These optimizations typically benefit CPU-intensive applications, but might cause a decrease of performance in applications that heavily rely on synchronous OpenGL calls such as glGet*.



2018-01-23 14:14

developer   ~0015498

I wonder if the issue can be reproduced in paraview. (I don't have a nvidia gpu right now so I can't try). If so, maybe they just haven't seen it yet, and finding the problem in another VTK client could help bump priority.

If not, maybe they do something differently in rendering or initialization.

(side note, I'm not sure what is the default, but when the setting is auto this issue can be avoided by setting process affinity to 1 CPU when initializing the GL context:



2018-03-31 01:23

administrator   ~0015632

Given the VTK version update, is this still an issue ?



2018-03-31 10:23

developer   ~0015648

Yes, it is still an issue. Image reslice in latest Slicer nightly (with updated VTK) is still much slower than Slicer-4.8.1.



2018-04-03 15:34

developer   ~0015651

I've discovered that by making the reslicing pipeline single-threaded, reslice speed is improved from about 10fps to 90fps:

This seems to solve all the regression compared to Slicer-4.8.1.



2018-04-12 19:31

administrator   ~0015669

This is still a big regression on mac. Turning on TBB seems to help. The packaging needs to be sorted out and then people can test the performance on different machines.



2018-04-29 21:27

developer   ~0015685

TBB completely solved the issue on high-end systems (desktops with NVidia GPUs).

However, on most laptops TBB helps but slice browsing is still about 5-10x slower compared to VTK7 (Slicer-4.8.1), for example on:

  • Surface book: Windows10, Intel HD Graphics 520/Nvidia GeForce
  • MacbookAir 2017: MacOSX, Intel HD Graphics 6000
  • Steve’s Macbook (he can give exact specs)

Profiling shows that most time is spent in Intel’s OpenGL driver. It seems that it is mostly due to calls made from vtkOpenGLTexture::Load.



2018-04-30 09:52

administrator   ~0015686

I see poor reslicing performance on all macs I've tried (current nightlies compared with 4.8.1).

The systems are:

  • late 2013 mac pro with amd firepro D700 6GB
  • mid 2012 mac book pro retina with nvidia geforce GT 650M 1GB

Some basic profiling indicates that the inefficient threading when executing the vtk pipelines, but not a lot of time is being spent in the graphics driver.



2018-04-30 09:58

developer   ~0015687

Some basic profiling indicates that the inefficient threading when executing the vtk pipelines,

Is this with TBB SMP backend?
Do you see any particular filters involved in this?
Could you try if this patch improves the situation (it replaces a few filters in the slice processing pipeline with a single in-place filter):



2018-04-30 11:18

administrator   ~0015688

So far I only tested the current Nightly, which I understand does not have TBB on mac.

I'll start building a release mode mac build and see if I am able to test the new pipeline.



2018-04-30 19:32

administrator   ~0015689

I built in release mode with TBB and the single-filter patch. It's "usable" but clearly laggy. I get 33fps on the Reslicing test with a full screen window (4k monitor). Dragging the slice slider is the most noticeable issue, but that almost seems more like an event management problem.



2018-05-15 10:59

administrator   ~0015710

Mac profile during frozen rendering (widgets updating)



2018-05-18 16:01

developer   ~0015723

Steve, could you help testing the followings?

  1. Can we force regular slice view rendering by setting adjusting DesiredUpdateRate?'Red').sliceView().renderWindow().SetDesiredUpdateRate(60)

Instead of 60, try also with 30, 10, 1, 0.0001 and let me know how it affects the update behavior. You may need to run it for green and yellow views as well, if you test the crosshair behavior as well.

  1. Have you noticed any difference in slice browsing in different slice views (red/yellow/green)?

  2. Check if this modification (prevent unnecessary 3D view updates during slice browsing) makes any difference: (will be included in tomorrow's nightly build). It should hugely improve performance when CPU volume rendering or similarly expensive 3D rendering is used, but I'm wondering if it may help in general.


2018-05-25 00:31

developer   ~0015736

Pull request submitted to CTK that fixes the (potentially indefinitely) delayed rendering on Mac, by decoupling quality control (render window's DesiredUpdateRate) from event compression (ctkVTKAbstractView's MaximumUpdateRate):



2018-05-25 13:29

developer   ~0015737

Fix has been integrated into CTK and git has was updated in Slicer r27203. This should fix the macOS specific update issue.



2018-09-18 13:19

administrator   ~0016024

We reviewed the issue during the 9/18/2018 hangout, and decided to mark it as resolved. It may pop up again/persist in the macOS version, but we will open a new issues if that occurs.

Issue History

Date Modified Username Field Change
2018-01-17 16:12 lassoan New Issue
2018-01-17 16:12 lassoan Status new => assigned
2018-01-17 16:12 lassoan Assigned To => jcfr
2018-01-17 16:16 lassoan Note Added: 0015479
2018-01-23 14:14 inorton Note Added: 0015498
2018-02-22 12:48 jcfr Relationship added has duplicate 0004481
2018-03-02 11:27 jcfr Relationship added related to 0004423
2018-03-02 16:05 jcfr Tag Attached: vtk-opengl2
2018-03-03 00:56 jcfr Summary OpenGL2: Reslicing speed can be very slow on Windows => VTK OpenGL2 Backend: Reslicing speed can be very slow on Windows
2018-03-31 01:23 jcfr Note Added: 0015632
2018-03-31 01:23 jcfr Status assigned => feedback
2018-03-31 10:23 lassoan Note Added: 0015648
2018-03-31 10:23 lassoan Status feedback => assigned
2018-04-03 15:34 lassoan Note Added: 0015651
2018-04-12 19:30 pieper Severity minor => major
2018-04-12 19:31 pieper Note Added: 0015669
2018-04-29 21:27 lassoan Note Added: 0015685
2018-04-30 09:52 pieper Note Added: 0015686
2018-04-30 09:58 lassoan Note Added: 0015687
2018-04-30 11:18 pieper Note Added: 0015688
2018-04-30 19:32 pieper Note Added: 0015689
2018-05-15 10:59 pieper File Added: Screen Shot 2018-05-15 at 10.58.10 AM.png
2018-05-15 10:59 pieper Note Added: 0015710
2018-05-18 16:01 lassoan Note Added: 0015723
2018-05-25 00:31 lassoan Note Added: 0015736
2018-05-25 13:29 lassoan Note Added: 0015737
2018-09-18 11:03 sjh267 Status assigned => resolved
2018-09-18 11:03 sjh267 Resolution open => fixed
2018-09-18 13:19 sjh267 Note Added: 0016024