Community
Arnold GPU Forum
General discussions about GPU rendering with Arnold.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Arnold GPU - Behavior/Stress Test

7 REPLIES 7
Reply
Message 1 of 8
am_wilkins
521 Views, 7 Replies

Arnold GPU - Behavior/Stress Test

Hello,

 

I'm doing some "stress testing" with Arnold GPU (Solaris+HotA) and trying to find what kind of scene complexity I can render with the GPU I have on hand.

 

I've noticed some strange behavior and trying to figure out what the Arnold GPU engine is doing.

When I render with the CPU, the scene only uses around 33GB of system RAM. Roughly takes around 4mins to start rendering.

However, once I fire off a GPU render Arnold spends 8mins loading close to 90GB into system RAM, then loads about 11GB into VRAM and finally starts rendering.
Then once I cancel the render and do a "Reset Arnold" I had to wait 10mins for Arnold to unload the 90GB from system RAM before Houdini would become responsive again.

It felt very frustrating to have x2 extremely long waiting periods while just running a "quick" in-scene render test.

 

Is this the experience I should be having?

Why is near triple the amount of system RAM being generated with a GPU render?

I don't have logs available right now, it's just some initial in-scene testing switching between CPU and GPU. If logs are required for further investigation, I can try to provide some once I have capacity.

 

 

All the best,

amwilkins

--

Houdini Core Version 19.5.569
Arnold Core: 7.2.2.0

HotA: 6.2.2.0

CPU: AMD Ryzen TR 3990x

RAM: 128GB
GPU: NVIDIA RTX A4000
OS: Windows

7 REPLIES 7
Message 2 of 8
Stephen.Blair
in reply to: am_wilkins

Doesn't sound typical to me.

Logs are always a good idea, especially for this type of question.

Was the the first time GPU render that required pre-population?



// Stephen Blair
// Arnold Renderer Support
Message 3 of 8
am_wilkins
in reply to: Stephen.Blair

Thanks for the reply Stephen, I'm trying to gather more data before posting again.

Having a few glitches in the matrix, that I'm trying to pin down.

1) Renders locally on GPU, however uses tons of system RAM. It's my assumption that Arnold GPU doesn't have out of core rendering yet, so this is still very weird behavior.
2) Same scene doesn't render on a farm node with the same specs, runs out of VRAM.
3) Possible differences between Husk and Kick

Will let you know as I have more info.

 

amwilkins

Message 4 of 8
Stephen.Blair
in reply to: am_wilkins


@am_wilkins wrote:

Thanks for the reply Stephen, I'm trying to gather more data before posting again.

Having a few glitches in the matrix, that I'm trying to pin down.

1) Renders locally on GPU, however uses tons of system RAM. It's my assumption that Arnold GPU doesn't have out of core rendering yet, so this is still very weird behavior.
2) Same scene doesn't render on a farm node with the same specs, runs out of VRAM.
3) Possible differences between Husk and Kick

Will let you know as I have more info.

 

amwilkins


GPU renders will use RAM for things like geometry, subdiv, and displacement



// Stephen Blair
// Arnold Renderer Support
Message 5 of 8
am_wilkins
in reply to: Stephen.Blair

Thanks that's good to know!

 

I have some more information, whenever I try to use Husk to submit the job to our render farm—I constantly get "Out of Memory" errors (Using the Arnold GPU) even with 99% scene contents removed from the scene.

 

However, when I manually (on my local PC) Kick the same USD file that Husk errors on then it render successfully.

 

Why is Husk preventing the render from completing and causing "out of memory" errors, when compared to Kick?

 

---
Whenever I try to do a GPU render on the farm with Kick I get this error:

R145| Error in this log file (158): stderr: coding error (secondary thread): in _failget at line 567 of s:\gocd\pipelines\kook\kook\usd\build\usd-22.11_windows-x86_64_static_vc-14.2_cxx14\pxr\base\vt\value.cpp -- attempted to get value of type 'vtarray<float>' from vtvalue holding 'float' 

 

We have no path at our studio with "s:\gocd\pipelines\".

Is this something related to Arnold code?

 

Additionally, as per my other thread—I'm unable to render with kick both due to this error and also textures not working in the latest Arnold version.

 

 

all the best,

amwilkins

Message 6 of 8
Stephen.Blair
in reply to: am_wilkins


@am_wilkins wrote:

Thanks that's good to know!

 

I have some more information, whenever I try to use Husk to submit the job to our render farm—I constantly get "Out of Memory" errors (Using the Arnold GPU) even with 99% scene contents removed from the scene.

 

However, when I manually (on my local PC) Kick the same USD file that Husk errors on then it render successfully.

 

Why is Husk preventing the render from completing and causing "out of memory" errors, when compared to Kick?

 

---
Whenever I try to do a GPU render on the farm with Kick I get this error:

R145| Error in this log file (158): stderr: coding error (secondary thread): in _failget at line 567 of s:\gocd\pipelines\kook\kook\usd\build\usd-22.11_windows-x86_64_static_vc-14.2_cxx14\pxr\base\vt\value.cpp -- attempted to get value of type 'vtarray<float>' from vtvalue holding 'float' 

 

We have no path at our studio with "s:\gocd\pipelines\".

Is this something related to Arnold code?

 

Additionally, as per my other thread—I'm unable to render with kick both due to this error and also textures not working in the latest Arnold version.

 

 

all the best,

amwilkins


That's an error from USD
The path is from the source code used to build the libraries, so it's from the dev environment of whoever built USD.

husk renders ok with Arnold GPU and a very simple scene on my machine



// Stephen Blair
// Arnold Renderer Support
Message 7 of 8

With another scene, not too complex, I can repro.
With USD Render ROP and husk, GPU gives an error message about memory.
Yet in a running Maya instance, I can render the same scene with just 4GB of GPU memory (I have 12 free). But that's a regular Maya scene, I'll try with usd too...



// Stephen Blair
// Arnold Renderer Support
Message 8 of 8
am_wilkins
in reply to: Stephen.Blair

Okay cool. Sounds like my situation as well. However, I was mainly saving to "USD" and then doing a Husk/ Kick command-line render from there.


Phew, glad you can repro!

 

 

all the best,

amwilkins

 

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums