# Commit 69e26835e would burn my discrete GPU!

**URL:** <https://discourse.slicer.org/t/commit-69e26835e-would-burn-my-discrete-gpu/1839>\
**Category:** Development\
**Created:** [January 14, 2018, 8:23pm UTC](https://discourse.slicer.org/t/commit-69e26835e-would-burn-my-discrete-gpu/1839 "2018-01-14T20:23:19Z")\
**Posts on this page:** 10\
**Page:** 2

<div class="post-metadata">

**Author:** ![Sankhesh\_Jhaveri](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/sankhesh_jhaveri/32/1081_2.png) [@Sankhesh\_Jhaveri](https://discourse.slicer.org/u/Sankhesh_Jhaveri)\
**Post date:** [January 17, 2018, 9:37pm UTC](https://discourse.slicer.org/t/commit-69e26835e-would-burn-my-discrete-gpu/1839/21 "2018-01-17T21:37:42Z")

</div>

@jcfr Why not just run `ctest` for the particular test? It will report a failure if the test times out.

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [January 17, 2018, 10:46pm UTC](https://discourse.slicer.org/t/commit-69e26835e-would-burn-my-discrete-gpu/1839/22 "2018-01-17T22:46:55Z")

</div>

Yes. Good point. we would just have to make sure the timeout is not 3600s.

---

<div class="post-metadata">

**Author:** ![chir.set](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/chir.set/32/66982_2.png) [@chir.set](https://discourse.slicer.org/u/chir.set)\
**Post date:** [January 17, 2018, 10:50pm UTC](https://discourse.slicer.org/t/commit-69e26835e-would-burn-my-discrete-gpu/1839/23 "2018-01-17T22:50:40Z")

</div>

> [@Sankhesh\_Jhaveri](#):
>
> would you be able to run git bisect to isolate the VTK commit that introduced this issue?

I’ll look into that as from tomorrow evening, will be busy in OR tomorrow.

---

<div class="post-metadata">

**Author:** ![chir.set](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/chir.set/32/66982_2.png) [@chir.set](https://discourse.slicer.org/u/chir.set)\
**Post date:** [January 18, 2018, 12:01pm UTC](https://discourse.slicer.org/t/commit-69e26835e-would-burn-my-discrete-gpu/1839/24 "2018-01-18T12:01:25Z")

</div>

> [@Sankhesh\_Jhaveri](#):
>
> would you be able to run git bisect to isolate the VTK commit that introduced this issue?

> [@Sankhesh\_Jhaveri](#):
>
> We were able to test this on the same GPU on a mac with proprietary AMD drivers

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.

---

<div class="post-metadata">

**Author:** ![chir.set](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/chir.set/32/66982_2.png) [@chir.set](https://discourse.slicer.org/u/chir.set)\
**Post date:** [January 21, 2018, 10:47am UTC](https://discourse.slicer.org/t/commit-69e26835e-would-burn-my-discrete-gpu/1839/25 "2018-01-21T10:47:53Z")

</div>

> [@Sankhesh\_Jhaveri](#):
>
> would you be able to run git bisect to isolate the VTK commit that introduced this issue?

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 Testing
> 
> 0a80c1818ce96c8edc785b11532361780ab6b2ae : 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.

---

<div class="post-metadata">

**Author:** ![chir.set](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/chir.set/32/66982_2.png) [@chir.set](https://discourse.slicer.org/u/chir.set)\
**Post date:** [January 29, 2018, 8:25pm UTC](https://discourse.slicer.org/t/commit-69e26835e-would-burn-my-discrete-gpu/1839/26 "2018-01-29T20:25:21Z")

</div>

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 !

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [January 29, 2018, 11:18pm UTC](https://discourse.slicer.org/t/commit-69e26835e-would-burn-my-discrete-gpu/1839/27 "2018-01-29T23:18:11Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![chir.set](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/chir.set/32/66982_2.png) [@chir.set](https://discourse.slicer.org/u/chir.set)\
**Post date:** [March 31, 2018, 1:39pm UTC](https://discourse.slicer.org/t/commit-69e26835e-would-burn-my-discrete-gpu/1839/28 "2018-03-31T13:39:51Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [April 1, 2018, 1:07am UTC](https://discourse.slicer.org/t/commit-69e26835e-would-burn-my-discrete-gpu/1839/29 "2018-04-01T01:07:51Z")

</div>

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:

```auto
cd VTK
gitk 590b341..7f00e99 ./Rendering/OpenGL2/

```

- [590b341](https://github.com/kitware/VTK/commit/590b341): This corresponds to the VTK version (without Slicer/VTK patch) associated with Slicer commit [r26830](http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=26830)
- [7f00e99](https://github.com/kitware/VTK/commit/7f00e99): This corresponds to the VTK version used in the latest Slicer [r27113](http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=27113)

Now, you mentioned that

> [@chir.set](#):
>
> SimpleRayCast GPU rendering also works as expected on my discrete R7 M270 GPU, with VTK commit e42e7c4b76.

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](https://github.com/Kitware/VTK/compare/7f00e99...e42e7c4b76)

 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/e/1/e1aed224e4548be23485a13a80c3e8ae23217d67.png)

I will test and update the version currently used in Slicer.

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [April 1, 2018, 1:16am UTC](https://discourse.slicer.org/t/commit-69e26835e-would-burn-my-discrete-gpu/1839/30 "2018-04-01T01:16:24Z")

</div>

For reference, here is the PR updating VTK in Slicer: [https://github.com/Slicer/Slicer/pull/928](https://github.com/Slicer/Slicer/pull/928)

[Previous page](https://discourse.slicer.org/t/commit-69e26835e-would-burn-my-discrete-gpu/1839.md?page=1)