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.

Details:

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
(source: https://devtalk.nvidia.com/default/topic/538342/linux/app-runs-only-with-__gl_threaded_optimizations-1-whats-it-do-/)

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*.
(source: https://www.phoronix.com/scan.php?page=article&item=nvidia_threaded_opts&num=1)

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: https://github.com/sgothel/jogl/commit/70c6a54fa2b8dec)

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:

• 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.

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.

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

@pieper
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): https://github.com/lassoan/Slicer/commit/8be0aaa03544f361d0e176098cbb8c8f7f00b9c3

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)

Steve, could you help testing the followings?

1. Can we force regular slice view rendering by setting adjusting DesiredUpdateRate?

slicer.app.layoutManager().sliceWidget('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.

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

3. Check if this modification (prevent unnecessary 3D view updates during slice browsing) makes any difference:
   https://github.com/Slicer/Slicer/commit/c11511d539d1b65141ec1d6ba46b6615ec5a1ec3 (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.

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.

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.