cycles - bad memory managment

Support Technical Support
#1

Hi everyones. I’m on this personal project and i’m having problems with the vram of my gpu (gtx 590)

here some shot to show you the issues. The scene in basically on 2 layer, forniture on layer 2, on layer 3 o have some heavy geometry like a bedcover and boxing bag, off the first image just as a geometry of a net.

As you can see poly count 1.166.102, render process end in 21 min for 2000 samples.

http://i.imgur.com/SGxRmSGl.jpg

Here’s i’ve turn on layer 3, poly count goes up to 1.442.400, just about 1 min more.

http://i.imgur.com/oqP32Qql.jpg

when the render above start, the firts 2 tiles looks ok and everything go ahead normally, just as showed in the image below.

http://i.imgur.com/SWZtcYrl.png

but if i turn on the net that’s what happen one of the tile (one of the core of the the 2 of the 590) and the timeing. Basically one of them goes ahead and the other one goes really slow. Polygons are now less the before how ever it looks like an heavy scene.

http://i.imgur.com/o00oOjml.png

In past tests it helps a lot turn on the progressive refine option, but not anymore, and actually when this slowed tiles things happens the viewport render was just slow the same, and if i eneble the progressive refine option the render stops after few second reporting a memory block error.

i’ve got a fast shot in octane and the memory status it’s just almost empty and if i add some grass (on other layer) as geometry, a lot of it (not proxy, actual geometry), i’ve still have space.

http://i.imgur.com/GUn2mKAl.jpg

any thought? it is possible the my blend file have some unwanted data that cause this?

#2

reporting a memory block error

This. You have bug in Nvidia driver, or faulty hardware. Maybe CUDA internal memory manager overlook something that do bad things for that tile. Try to change tile size. You can mtigate it by reducing polygon number of texture resolution, or try another Nvidia driver, or tweak maybe CUDA control panel settings if there is one. Images too small to see what in red circles.

Cycles preprocess all data before start any tile, there is no any on-fly on-demand things related to scene data in process. Obviously, problem is in stage when next tile data copied to another idle rendering GPU device. Now we call Nvidia driver and hope for best untill it render tile and return to main Cycles program.

#3

hi there, thanks for the reply. Meanwhile i’ve done some test and i’ve find out that could be something releated to the transmission pass. Infact i’ve been able to render at normal speed turning down the transmission bounces to 1, all the other passes seems to be not an issues at values of 4, 5, 10 or whatever, instead a value of 2 for the transmission bounces, basically, slowdown everythings. That’s obviously bad cause now all my glass looks almost black!

#4

Correction.

I still belive is a broblem releated to transmission (glass or similare -not simple transparencey), but i can even have transmission values up to 1 providing general bounce at 1.

So: 1 general bounces and 2 transmission bounce = no problem
2 general bounces and 1 transmission bounce = no problem

2 bounce on both sides = problem!

#5

Cycles do not allocate any extra memory when more bounces used, except for Sobol random generator “direction” vectors, and use it as special hidden texture. That size depend on maximum bounce possible. So, i very doubt that changing bounce number matter. Passes implemented almost same as no passes case, difference is have more output buffers and few internal “conditional” if() statements and now it write not only pixel color but extra data. that take zero extra memory (only buffers, but as you note you use passes in any cases so change is zero, not depend on any other settingds.)

Your images too small, cannot read any settings numbers. Still i think that problem in extreme memory pressure to GPU, that trigger some corner case in NVidia CUDA internal memory manager, it place BVH chunk in wrong place or with high access cost, maybe hardware bug related as well. Octane use different BVH algorighms and maybe lucky not trigger that.

#6

i’m sorry i thought that the images were zoomable.
I’m uploading them as attachment in 2 post since i can upload 3 per time.

test03.PNG1920×1085 334 KB

test04.jpg1920×1080 518 KB

test01.jpg1920×1080 518 KB

#7

here’s the others

Attachments

test05.PNG1919×1085 327 KB

#8

So i’ve tried to change tile size, no changes. So i’ve tried to change the tile order, from right to left and i’ve noticed that about half of the image goes fine…and the other half suffer of the problem above. Same happens in the viewport rendering.
I’ve thought that some how could all this was related to the shadow casting of the net or any way with it’s shader and how it’s casted (since the problem looks not related to poly count but to the nature of the geometry of the net, at least in the way the engine interpret it)

Apparently there’s someting in here, cause i set a holdout shader for the net, which cast the shadows but make appear the object invisible to the passes. And all work good. In light of that i’ve tried to turn of the visibility of the object to the camera firts (with a diffuse material on it), but nothing happend. Instead i’ve turn on back the visibility to the camera and than off the one to the transmission, and all works fine, finally!

It’s a work around, but it works…untill it will show up again i guess :slight_smile: