@jcfr Why not just run ctest for the particular test? It will report a failure if the test times out.
Yes. Good point. we would just have to make sure the timeout is not 3600s.
I’ll look into that as from tomorrow evening, will be busy in OR tomorrow.
Well, I installed the AMDGPU-PRO proprietary driver on my RX480 PC and Volume Rendering just works.
It used to work with VTK9 up to commit 486c6ee7a without amdgpu-pro. I suppose commit 69e26835e now requires OpenCL explicitly to work among many other changes in VTK. It was so conveniant for Slicer to just work fully without porting packages built for other distros. So either I continue with 486c6ee7a or I use amdgpu-pro.
I think that bisecting VTK becomes superfluous. I can still do it if you think it’s useful.
Regardless of Volume Rendering working as expected with amdgpu-pro proprietary package on Linux, and accounting in particular that Volume Rendering used to work as expected without the proprietary package, I performed the bisect of VTK with the following results :
db38b04f8d90204a5e2dccbdacfefc4ded0d3ee0 : BAD
ca174d0ff382ba25d9ebf949e201a84351f63963 : BAD
e5b528dbfefd8ea934a507eb6b9f6e4ad74bd0f4 : BAD
92310ce2ae77413cf027281ffe3ff79981c38f36 : BAD
4722a46045ebab9695a944ff5f0e3816e2530f49 : BAD
69821aeec42b13ab776bcf2113068c686ed25741 : BAD
a632f77e3fa955dbf17813a803ddae43a9675021 : BAD:040000 040000 79dd4489981278880c229b9cb216bc12f06e9651 5cd872014cfc65a4d021486b8cde01d69aacbed1 M Common
:040000 040000 b004405dd3fca6b649fcb1c72d3e015505647156 0491e6089fcba3fcdb49538ec37ea44bdee61513 M Rendering
:040000 040000 472990bf77ee19ab98b00737c486529cc347cc37 975b1195e27fd6c93362d5c2386cff7b51aaa4a7 M Testing0a80c1818ce96c8edc785b11532361780ab6b2ae : GOOD
0e852c83d0e1cceff29e4df74b2059a085ed8518 : GOOD
41f2ba3ae8e8c25223d32a37191b971ef839cd38 : GOOD
887c5065ec2220be04b105ce1d966c5162e729af : GOOD
All tests were done with SimpleRayCast. Up to the first bad commit after db38b04f8d (start), Slicer was rebuilt with the corresponding VTK commit by modifying SuperBuild/External_VTKv9.cmake. Slicer’s behaviour was similar to SimpleRayCast, and the latter only was used afterwards. ctest always freezes my laptop with all commits, defeating automation.
This unexpected behaviour is observed with the Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445] (lspci output, laptop dGPU) and with the Ellesmere RX480 GPUs.
Volume Rendering works normally with the Kaveri [Radeon R6 Graphics] (laptop iGPU) and the Oland PRO [Radeon R7 240/340] GPUs.
All this without any proprietary package.
I don’t know if the Slicer/VTK teams would consider if :
- the proprietary package is mandatory on Linux,
- the open source amdgpu kernel module or the open source xf86-video-amdgpu package is faulty,
- commit a632f77e3 can be reviewed for greater usability of VTK derived software on Linux.
Please note that I am posting these for information purposes only, though it’s clear the third option would suit me best.
Regards.
I noticed that if ‘Crop Enable’ checkbox is ticked in Volume Rendering, with or without being unchecked next, after having first selected a volume in the uppermost combobox, then Slicer does not freeze when the resulting 3D volume is rotated on those two failing GPUs.
I applied this patch and Slicer then behaves normally.
diff --git a/Modules/Loadable/VolumeRendering/Widgets/qSlicerVolumeRenderingModuleWidget.cxx b/Modules/Loadable/VolumeRendering/Widgets/qSlicerVolumeRenderingModuleWidget.cxx
index 8b92cc3a6..892e2d605 100644
--- a/Modules/Loadable/VolumeRendering/Widgets/qSlicerVolumeRenderingModuleWidget.cxx
+++ b/Modules/Loadable/VolumeRendering/Widgets/qSlicerVolumeRenderingModuleWidget.cxx
@@ -353,6 +353,14 @@ void qSlicerVolumeRenderingModuleWidget::onCurrentMRMLVolumeNodeChanged(vtkMRMLN
// instead of whichever current one.
dnode->Modified();
}
+ /*
+ * Workaround nasty UI freeze with AMD RX480 and R7-260 GPUs
+ * http://discourse.slicer.org/t/commit-69e26835e-would-burn-my-discrete-gpu/1839/25
+ */
+ if (dnode->GetCroppingEnabled())
+ dnode->SetCroppingEnabled(false);
+ dnode->SetCroppingEnabled(true);
+ dnode->SetCroppingEnabled(false);
}
this->setMRMLDisplayNode(dnode);
Quite strange, as much as the unknown cause, as to how would this fix anything !
Interesting discovery. It would indicate that there could be an uninitialized variable somewhere, probably in the driver, It would be great of course if this issue could be tracked down and fixed at a level below Slicer because we would want to avoid hardware/driver specific code in the Slicer code base if we can avoid it (plus fixing at the source would have the most benefit for other users).
Slicer commit 0efdac696 works flawlessly without any patch. No UI freeze. And cropping in Volume Rendering works with Depth Peeling on also. Both for nightly build 20180331 from your repository, and for Slicer locally built from source on Arch. I guess it has to do with the VTK commit being used.
SimpleRayCast GPU rendering also works as expected on my discrete R7 M270 GPU, with VTK commit e42e7c4b76.
I wish to know what could have been the problem with 69e26835e, just out of curiosity.
Thanks.
Thanks for the update. Since a lot of changes happen in the last three month, it’s gonna be hard to pin point the exact change addressing the problems. To get more insight, you could locally try this command:
cd VTK
gitk 590b341..7f00e99 ./Rendering/OpenGL2/
- 590b341: This corresponds to the VTK version (without Slicer/VTK patch) associated with Slicer commit r26830
- 7f00e99: This corresponds to the VTK version used in the latest Slicer r27113
Now, you mentioned that
This corresponds to a version of VTK newer that the one currently used in Slicer, here is the difference: Comparing 7f00e99...e42e7c4b76 · Kitware/VTK · GitHub
I will test and update the version currently used in Slicer.
For reference, here is the PR updating VTK in Slicer: https://github.com/Slicer/Slicer/pull/928