Rhino 7 closes without any error message when rendering

[j.cpritchard]

Hi, this is my first post on the forum, so hopefully I put it in the right category and it isn’t too long or missing obvious information.

I’ve had a search through the forum but can’t find anything exactly like the problem I’m having, I did find this post, Crash when scrolling
It seemed more specific than my issue - but as it involves rendering and an AMD gpu maybe they’re related?

I’m not sure if this is a hardware issue or software issue, but I’ve been having problems with rendering since upgrading to Rhino 7, specifically trying out PBR textures.

It breaks down into two issues, the first I sort of resolved through bypassing it, the second is possibly related to the first and a bit more problematic.

I upgraded my machine from a Quadro M4000 (that had been in my previous machine) to a Radeon 5700xt a year ago, this worked fine with Rhino v6, and everything seemed to run OK.

The first problem I had was running with a rendered view in Rhino v7 with just the AMD card it would sometimes throw up a small window that said something similar to ‘Server is busy’ with a greyed out button and a ‘switch to …’ button.
Pressing the 'switch to. . ’ button opened windows start menu, I could launch a second instance of Rhino, but nothing I tried would remove the pop-up window or close the first Rhino window other than a force quit from task manager.

I found two ‘solutions’ to this problem, one was setting cycles to CPU rendering, which was much slower and less responsive, the other, which I stuck with, was to re-install the Quadro as a second card and use it just for CUDA in cycles.
This seemed to work really well, especially for keeping Rhino responsive while having a rendered view visible.
. . . that’s also my explanation for having a possibly slightly odd combination of graphics cards.

Then as I experimented more with textures I came across my second problem:
Rhino will just disappear without warning while rendering, this can happen in the viewport and but mostly in the dedicated render window.

It happens pretty consistently, The model I first noticed it one wasn’t particularly complex, but had 4 3K PBR materials applied to it. I recreated the same situation with the model with task manager open and noticed while rendering, along with the M4000 chugging along with ~90% ‘Compute_0’ and maybe 6Gb of VRAM used, the 5700xt’s VRAM would creep up in usage until it hit 8Gb, the same with system RAM it keeps creeping up until I hit 90%+ usage, at that point it will sit apparently stable for a few minutes more, but then Rhino will just close, or more accurately disappear, without error message as if it hadn’t have been running at all.
Just at that moment there will be a 100% spike in both the M4000 and 5700xt’s, usage.
I also monitored temperatures, the 5700xt never gets above 60ish, the M4000 sits at about 71, so neither are at danger of overheating.

I repeated the set up with a simple scene, a sphere, a cube and a ground plane, all with PBR textures and the same thing happens when I go to render it, RAM usage creeps up until it hits it’s limit, both GPU’s usage spike and Rhino closes.

I tried using ProRender as the renderer, it displays the same behavior, but with some of the textures not rendered properly and no focal blur is applied, but thats a different issue I guess.

I also tried CPU rendering in cycles, which worked better, but the 5700xt’s memory usage still rises until it hits 8Gb and the system RAM now rises to 98% then drops to 74% and repeats the cycle a couple of times before crashing in the same way, with a spike in both GPU’s usage and Rhino disappearing at the same moment.
It takes longer to crash, but maybe that’s just proportional to the slower speed of CPU rendering.
With CPU rendering Rhino does manage to make an autosave file and recognize that it didn’t close properly, which is more than with CUDA rendering or ProRender crashes.

I would assume if it was simply a lack of RAM I’d get a specific ‘out of memory’ type error and Rhino would close a bit more gracefully.

I’m hoping this is just a software bug relating to the AMD graphics card that can be resolved, given the current GPU market I really don’t want to have to upgrade from my 5700xt anytime soon, and I would prefer not to have to go back to the M4000 as my main GPU.

Here’s my systeminfo:

Rhino 7 SR2 2021-1-21 (Rhino 7, 7.2.21021.07001, Git hash:master @ 96ff97351fbdf5d2acdeaf781aea1577f2ff60f7)
License type: Commercial, build 2021-01-21
License details: Cloud Zoo

Windows 10.0.18363 SR0.0 or greater (Physical RAM: 32Gb)

Computer platform: DESKTOP

Standard graphics configuration.
Primary display and OpenGL: AMD Radeon RX 5700 XT (AMD) Memory: 8GB, Driver date: 12-4-2020 (M-D-Y). OpenGL Ver: 4.6.14757 Compatibility Profile Context 20.12.1 27.20.14501.28009
> Accelerated graphics device with 8 adapter port(s)
- Windows Main Display attached to adapter port #0
- Secondary monitor attached to adapter port #1

Secondary graphics devices.
NVIDIA Quadro M4000 (NVidia) Memory: 8GB, Driver date: 12-11-2020 (M-D-Y).
> Accelerated graphics device with 4 adapter port(s)
- There are no monitors attached to this device!

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: ATI Technologies Inc.
Render version: 4.6
Shading Language: 4.60
Driver Date: 5-15-2020
Driver Version: 26.20.15029.27017
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24 bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 8176 MB

Rhino plugins that do not ship with Rhino
C:\Users\Jon\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\AMDDenoiser\0.4.1\AMDDenoiser.Windows.rhp “AMDDenoiser.Windows” 0.4.1.0
C:\Users\Jon\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\NVIDIADenoiser\0.4.0\NVIDIADenoiser.Windows.rhp “NVIDIADenoiser.Windows” 0.4.0.0
C:\Users\Jon\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\ProRender\1.0.0.0\ProRender.Windows.rhp “ProRender” 1.0.0.0
C:\Users\Jon\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\raytraced-materials\0.1.3+v6.15\RaytracedMaterials.rhp “Raytraced Materials” 0.1.3.0

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 7\Plug-ins\Commands.rhp “Commands” 7.2.21021.7001
C:\Program Files\Rhino 7\Plug-ins\WebBrowser.rhp “WebBrowser”
C:\Program Files\Rhino 7\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 7\Plug-ins\RhinoScript.rhp “RhinoScript”
C:\Program Files\Rhino 7\Plug-ins\IdleProcessor.rhp “IdleProcessor”
C:\Program Files\Rhino 7\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 7.2.21021.7001
C:\Program Files\Rhino 7\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 7.2.21021.7001
C:\Program Files\Rhino 7\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI”
C:\Program Files\Rhino 7\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 7\Plug-ins\Alerter.rhp “Alerter”
C:\Program Files\Rhino 7\Plug-ins\RhinoCycles.rhp “RhinoCycles” 7.2.21021.7001
C:\Program Files\Rhino 7\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 7.2.21021.7001
C:\Program Files\Rhino 7\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 7\Plug-ins\Displacement.rhp “Displacement”

[nathanletwory (Nathan 'jesterKing' Letwory)]

@j.cpritchard

The first problem I had was running with a rendered view in Rhino v7 with just the AMD card it would sometimes throw up a small window that said something similar to ‘Server is busy’ with a greyed out button and a ‘switch to …’ button.

Sounds like you’re switching to the Raytraced mode, not Rendered.

When using the Radeon 5700xt please try:

Crash when scrolling through render settings

It seems compiling of kernels isn’t going as expected in thumbnail preview rendering. With the rendering panel hidden set the render device back to your GPU. Then change a viewport to Raytraced and click the running number in the right side of the HUD, change the number to something large, I use generally 999999 for this step. Let Rhino run for 10-20 minutes. You’ll see that after a short while the viewport changes to gray, that is expected. After the long wait change the viewport to Wireframe…

from the thread you linked.

@j.cpritchard

. . that’s also my explanation for having a possibly slightly odd combination of graphics cards.

Odd combination is fine. I have in my desktop: Radeon Pro WX9100 and Nvidia RTX A6000.

@j.cpritchard

C:\Users\Jon\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\AMDDenoiser\0.4.1\AMDDenoiser.Windows.rhp “AMDDenoiser.Windows” 0.4.1.0
C:\Users\Jon\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\NVIDIADenoiser\0.4.0\NVIDIADenoiser.Windows.rhp “NVIDIADenoiser.Windows” 0.4.0.0

If you’re running the denoisers while in the Raytraced mode - we’re currently leaking memory and it is being worked. So for now while Raytracing and you keep doing that for extended time turn off the denoiser.

@j.cpritchard

I also tried CPU rendering in cycles, which worked better, but the 5700xt’s memory usage still rises until it hits 8Gb and the system RAM now rises to 98% then drops to 74% and repeats the cycle a couple of times before crashing in the same way, with a spike in both GPU’s usage and Rhino disappearing at the same moment.

The GPU RAM isn’t used for this particular part, so it sounds a bit odd that GPU consumption keeps creeping up.

If you could please share your (simple) test file with me via https://rhino3d.com/upload?to=nathan@mcneel.com that’d be great. All weekend I’ve been working on different memory management fixes for Raytraced, so an extra file from a user to test with is only better.

[j.cpritchard]

Thanks for the response, I think I somewhat understand whats happening now.
-and yes, sorry, I meant Raytraced mode in the viewport, I was conflating it with the ‘Render’ tab/button.

I’ve turned all the post effects off in both the view port and the Rhino Render window, and it seems to be running fine now, with more stable memory usage.

If I turn a post effect back on, any of them, Is see memory usage start to creep up.

My guess to is that most of the post effects are handled by the systems main GPU, in my case the 5700xt, and the memory management problem happens when a post effect is applied.
On top of that if the effect is applied from the beginning of a long render it applies the effect to every sample, and the cumulative memory leak eventually fills up both the GPU and system RAM given a enough samples.
and if the viewport has had denoising on this also adds to the cumulative RAM usage creep.

This might explain why even though I had the cycles render set to CPU, the 5700xt’ VRAM usage was still creeping up, I think I’d left the ‘bloom’ effect on so it was applied to every Path Trace Sample.
I realize now that they are ‘POST’ effects, and so can be applied to the completed render after all the path traced samples have been done.

So I guess the issue is with Post Effects as a whole?

I did a long render on the M4000 with just NVIDIA denoiser applied, and the System RAM usage crept up, but 5700xt held more or less at 3.5Gb, (which still seems pretty high for just displaying the M4000’s output). Rhino still crashes as before once the RAM is maxed out.

The simple test file was literally a sphere and a cube on a ground plane, each with different PBR textures applied, Rhino crashed after I created it. I made a second one and uploaded it via the link you sent. Compressing it didn’t do much to the size of the file I’m afraid.

I updated my Radeon driver and cleared some space on my C drive, and the crashes aren’t quite as easy to recreate now, but do still happen eventually, also the Rhino crash report dialog window sometimes opens up now, which is an improvement.

After freeing space on the drive the memory now drops from 31Gb usage to 20Gb and starts rising again, Unsurprisingly this correlates to a lot of data being written to the C Drive, Does Rhino store temporary files outside of windows page file while rendering - if so is it possible to control which drive they are created on?

[nathanletwory (Nathan 'jesterKing' Letwory)]

Memory leak in post effect system is fixed in what will become 7.4. I’ll send you later today in a private message a new build with which you can test if this holds true also for you.

The temporary files are created in where-ever %TEMP% points

[brian (Brian Gillespie)]

RH-62353 is fixed in the latest Rhino 7 Service Release Candidate