@wegner wrote on mitk-users mailing list:Hi MITK team,
congratulations to the honorable mentioning at GTC; that's a big honor!I was looking at the latest release and was stumbling over the update rate of the 2D widgets when you do mouse interactions. The performance has dropped compared to the older releases. Do you know the reason for this and do you plan for a fix?
... if we could come back to the previous performance, using the semi manual segmentation tools would be much better.
Best regards to everyone,
Ingmar
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
MITK v2018.04.2 frame time measurements of interactions on Pic3d.nrrd with Segmentation Add Tool (GTX 1070, 1440p, 120 Hz refresh rate, 8-core i7 @ 4 GHz):
2d widgets: 8ms
3d widget: 2ms
1000/(3*8+2) = ~ 40 Hz
Changing slice in image navigator:
2d widgets: 10ms
3d widget: 40ms
1000/(3*10+40) = ~ 15 Hz
Comment Actions
Hi,
measurements on my side
mitk v2018.04.2 (zip downloaded from webside) with pic3d.nrrd (106.478KB), a fresh generated binary dataset and with Segmentation Add Tool (NVIDIA Quadro K5000, Full HD resolution, 60Hz refresh rate, three displays connected, Intel Xeon E5-2687w 3,4GHz (2 processors, 32cores in total), 64 GB RAM (I admit, a few years old, but still better than any standard PC ;) )
->measured with fraps
2d widgets: 20 Hz, going down over time
3D widgets: 60Hz, stable over time as no segmentation interaction is going on.
Changes in slice navigator:
axial slice: 1-2 Hz
My issue is rather the latter, so the widget interaction itself. Without activating the Segmentation Add Tool you are changing the slices of the other two 2D widgets when you press and hold left mouse button on the one 2D widget.
This is unbelivably slow (below 1Hz) in the new release. Did you encounter this?
I also tried with a laptop that was running well on the old MITK release.
When only having pic3d data set in DataManager (no plugin activated) and going through slices
I have 2Hz update rate on a 2D widget, constantly 60Hz on the 3D widget (limited by my monitor update rate).
Do you have no performance decrease on your side?
Thank you,
Ingmar
Comment Actions
Thanks for measuring! I downloaded the latest zip installer and roughly did what I think you did as well. Recorded at 1080p @ 60 Hz, encoded in 720p (same H/W as mentioned in my last post). I think this is completely different from your experience, right?
Comment Actions
Wow, that looks nice!
No, that's not what I have seen on my desktop, or a laptop or a Windows virtual machine, that used to work well with the older MITK version (2016.03.0).
I will check on a recording solution (which one did you use?) and do the same on my side...
Thanks,
Ingmar
Comment Actions
(Didn't see latest comments from yesterday evening, was typing the following while only the initial comments of Stefan were visible in my browser)
May I add some measurements for following setup:
- installers taken from mitk.org
- Windows 10, Intel Xeon E5-2643 @ 3.4GHz, 64GB RAM, Nvidia NVS310 [edited: previously this said NVS210] (yes that GPU is not the fastest but is more than good enough for a simple Pic3D rendering)
- Pic3D.nrrd loaded, axial view maximized with crosshair visible, only Data Manager and Image Navigator views visible. Render window size is approximatively 1500x850.
- fps measured using fraps
Dragging the crosshair inside the render window using the mouse:
- MITK v2018.04.2: around 9fps
- MITK v2016.11: around 16fps
Dragging the Image Navigator slider for "Axial" using the mouse:
- MITK v2018.04.2: around 14fps
- MITK v2016.11: around 24fps
I am currently trying to move to the new release. Those numbers look like a bad regression to me.
Comment Actions
My bet is on the "new" OpenGL 3.x rendering backend of VTK as we didn't change anything else in this area of MITK in the past years. Especially non-mainstream GPUs from around 2011-2012 are the ones which tend to somehow work but not in a satisfactory way regarding OpenGL 3.x. Unfortunately Nvidia doesn't continue to provide current drivers for GPUs this old as far as I know which would be usually my first advise to check.
Comment Actions
@wegner It's the Nvidia screen recording which comes right with the driver resp. GeForce Experience application and utilizes the GPU directy to record the screen content. Not sure if it works with a 2012 GPU, though.
Comment Actions
@maleike NV210? According to google this GPU was released in 2003. I'm surprised that you can see anything at all as OpenGL 3.x was released between 2008 and 2010. As you guys have quite powerful CPUs and lots of RAM I guess you have rather recent workstations except the GPUs. Is there a specific reason to stick with such old GPUs? No offense here, it's just noticable. You get a HUGE performance boost even with a silent low-end GTX 1050 without extra power supply for around 140 €.
Comment Actions
Oops, that was a typo. My card is actually a NVS310 (NVS310). That is also end-of-life but fast enough to cut through small image stacks and good-enough for simple image / mesh display.
Comment Actions
Hi,
after updating my graphics card driver to the newest available (430.39) the issue still exists. I will check on VTK side next and see if it is related to it.
Thanks,
Ingmar
Comment Actions
I also checked on my notebook from 2011 with a GeForce 540M and I have similar framerates compared to @maleike. I also checked all the different GPU load indicators with GPU-Z and messing around in the 2d views does not trigger such an old GPU to even yawn. CPU is also not sweating so I guess it could be something related to memory access or transfer.
Comment Actions
A profiling session revealed that a substantial amount of time during interaction with the 2d widgets is spent by the ITK object factory in the context of mitk::BaseGeometry when creating new instances of itk::BoundingBox, itk::VectorContainer, and itk::ScalableAffineTransform.
I replaced their itkNewMacro with an itkFactorylessNewMacro, then had to do a minor adaption of a line of code in MITK for obscure language reasons and the hot path during execution completely changed.
It's hard to come up with comparison on my machine as it performs pretty fast in both cases but I believe there is quite a noticable difference.
I'll create a branch so we can test the difference on more severely affected machines.