View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004496||Slicer4||Core: Rendering||public||2018-01-17 16:12||2018-05-25 13:29|
|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.
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:
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.
I see poor reslicing performance on all macs I've tried (current nightlies compared with 4.8.1).
The systems are:
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.
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.
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.
Mac profile during frozen rendering (widgets updating)
Screen Shot 2018-05-15 at 10.58.10 AM.png (341,710 bytes)
Screen Shot 2018-05-15 at 10.58.10 AM.png (341,710 bytes)
Steve, could you help testing the followings?
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.
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): https://github.com/commontk/CTK/pull/804.
Fix has been integrated into CTK and git has was updated in Slicer r27203. This should fix the macOS specific update issue.
|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|