View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004496||Slicer4||Core: Rendering||public||2018-01-17 16:12||2018-04-12 19:31|
|Product Version||Slicer 4.9.0|
|Target Version||Slicer 4.9.0||Fixed in Version|
|Summary||0004496: 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.
Disabling "Threaded optimization" in NVidia settings seems to mostly solve the problem: speed is consistently around 50 FPS.
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.
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*.
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
Given the VTK version update, is this still an issue ?
Yes, it is still an issue. Image reslice in latest Slicer nightly (with updated VTK) is still much slower than Slicer-4.8.1.
I've discovered that by making the reslicing pipeline single-threaded, reslice speed is improved from about 10fps to 90fps: https://github.com/Slicer/Slicer/pull/930
This seems to solve all the regression compared to Slicer-4.8.1.
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-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|