Vray GPU - bring stuff out of Vram? possible?

[tomtnt]

Hallo,
I am quite new in GPU computation, but some jobs are already done. Anyway, it is quite stress-full to get in size of Vram (i have only 11 GVram) and NV-link seems to me quite expensive. I have suddenly found Centileo GPU render. Never test it, but went through the features of this render and they write:

CentiLeo works entirely on the GPU (CUDA based) at the speed of GPU and at the same time the amount of geometry and textures of the scene can be much larger than GPU memory capacity thanks to the novel and efficient caching system which utilizes main RAM. However, it is also very fast for small and moderate scenes...

Hmmmm...is really possible to do something like this? Use the GPU just like CPU? without limits of Vram?
Tomas

[super gnu]

it is certainly possible. vray already does out-of-core textures. but the issue with geometry is pcie bandwidth.

notice they say "fast for small scenes" the flipside of this is when you use geometry caching, things slow riiigt dooown.

i expect at some point vray will implement out-of core geometry since it gives you the option to render larger scenes without hoping it doenst crash.. slow rendering is better than no rendering, right?

in any case, with pcie4.0 around the corner, maybe the bandwith issues will be less severe soon.


note: when you say "nvlink seems expensive" well, you do have to buy minimum 2x 2080 rtx cards. but as well as the nvlink you also get a lot of rendering horsepower

[Muhammed_Hamed]

Vlado talked about out of core last Summer, CG are working on implementing it now
Redshift, Octane 4 and Cycles offer out of core tech just like what you described, but problem is that going out of core slows down rendering a lot(I don't know if this will be the case with Vray, we will see)
Redshift documentation recommends users to stick to whatever fits in VRAM, you only go out of core as your last option really due to the massive slowdown. I have tested out of core in RS and Cycles, rendering is way slower when you go out of VRAM
I don't think you would want to go out of core in a production environment. For Vray we already have hybird rendering, so you can render the GPU scenes with C++/CPU and get the exact same results or you can use a local CPU based render farm
Also NVlink with 2x2080ti is quite affordable and much better solution as you barely lose any performance with NVlink.. Vray is the only renderer that supports NVlink, you can have up to 48 GB of VRAM with 2x Titan RTXs

[Muhammed_Hamed]

vray already does out-of-core textures.

No, it is not implemented yet as far as I know. You will get an error"cannot allocate enough memory"

[super gnu]

hm a matter of terminology, but id argue that the "on demand/mip mapped" option for gpu textures does essentially the same thing. only loading what is necessary of each texture and scaling the res dynamically before loading to gpu ram.

[^Lele^]

yep. however it can't unload to make room for newer stuff.

[Muhammed_Hamed]

On demand doesn't affect performance like going out of core, you don't deal with bandwidth issues like what you explained above

[^Lele^]

hm a matter of terminology, but id argue that the "on demand/mip mapped" option for gpu textures does essentially the same thing. only loading what is necessary of each texture and scaling the res dynamically before loading to gpu ram.

Not entirely exactly (my bad for reading it cursorily the first time around.).

Mip-Mapped textures allow for RAM and computation savings, but deal exclusively with one type of scene data, which *has* to fit in the GPU VRAM (you can still run out of ram with them, in other words.).
They do not suffer from *any* penalty of the type tiled textures or proxies, or indeed OOC, would.
The price for memory clearing and re-writing can be seriously big, as anyone which reached the end of system RAM may testify: better than swapping to disk, surely, but not so much better as to let one forget they are out of RAM.

OOC means data is stored into system RAM.
From there, it still needs uploading to the GPU VRAM for usage.
The main issue in this, i gather, is the roundtrip: there is physically a log way for data to go back and forth, and it's not cheap, often negating the speed benefits of a GPU render.

This however isn't just limited to textures, but rather uses the system ram as a storage for *any type* of scene data.
It also goes without saying that there has to be another penalty for the clearing and re-occupation of the GPU's VRAM (just as there is for the dyn. geo / textures memory pools on CPU.), as there is no way (was? maybe things changed of late, but i wouldn't know.) the data could be used directly from the system RAM.

Further, there may be cases where system RAM itself isn't enough, as there are today for CPU renders, so the number of techs to make work in unison grows and grows, and it's seriously difficult to marry them in a cohesive, coherent way, which also keeps performance viable.

What OOC enables, of course, is flexibility: rather than not rendering at all on GPU, it's perhaps more cost effective to render slower, but on the same hardware and engine combination.

I of course stand to be corrected by any of the coders. ^^

[super gnu]

ok i stand corrected. i think most of us appreciate that full out-of-core rendering would be dog slow, however some kind of "fallback" to a system like that would be seriously useful, as you would always (within system ram limits i expect) be able to render.

the number if times ive started a job on gpu then, near the end, been forced to switch to cpu and go through the whole scene tweaking to get similar result, due to client adding an unexpected pile of displacement or textures, its probably the majority of jobs ive tried on gpu.. the missing features can usually be worked around if you start the job on gpu... but a 12gb ram limit is a hard wall to hit.

obviously if you have the cash, then larger gpu memories are available.. but then it starts being totally cost ineffective vs cpu rendering.

edit.. there is always the fallback of cuda on cpu i suppose.. but ive found that is much slower than just swapping over to vanilla vray.

[^Lele^]

I personally tend to agree.
Until there will be enough VRAM available, married with enough compute power, and ideally a working API or two, at a low enough price, GPU rendering will remain a niche product: great when it fits the bill, but less flexible than vanilla CPU when at the -sharp- confines of its memory capacity.
If one can however afford the hardware, and be comfortable with the (few, these days.) limitations, then it can provide for quite the exhilarating experience.
Good thing we have a (viable!) choice. ^^

[Micha]

OOC means data is stored into system RAM.
From there, it still needs uploading to the GPU VRAM for usage.
The main issue in this, i gather, is the roundtrip: there is physically a log way for data to go back and forth, and it's not cheap, often negating the speed benefits of a GPU render.

So, instead using the RAM couldn't an unused VRAM be used for OOC, but at higher speed than RAM? For example I could imagine to render per 2x2080ti and to use a 1080ti for storing OOC textures only.

[^Lele^]

So, instead using the RAM couldn't an unused VRAM be used for OOC, but at higher speed than RAM? For example I could imagine to render per 2x2080ti and to use a 1080ti for storing OOC textures only.

That'd be a similar trip through the system buses, unless the 1080 started rendering.

[Muhammed_Hamed]

The point of GPU rendering for most people is speed, out of core slows things down quite a lot, to the point where you would be better rendering on CPU instead
I have used out of core in Cycles and Redshift, and it has been useless in any production scenarios. GPUs would be at 40-50% utilization...
No idea how this will play with V-ray, I wouldn't expect it to be any better honestly. I barely run out of VRAM on my scenes and I will be upgrading to NVlink and RTX soon, I don't care much about OOC
If I ever run out of VRAM, I can use the Cuda engine in CPU mode, which also works on Chaos Cloud. Or from the start, I would be using Vray CPU(which has a lot more features than Vray GPU)

[^Lele^]

The point of GPU rendering for most people is speed, out of core slows things down quite a lot, to the point where you would be better rendering on CPU instead
I have used out of core in Cycles and Redshift, and it has been useless in any production scenarios. GPUs would be at 40-50% utilization...
No idea how this will play with V-ray, I wouldn't expect it to be any better honestly. I barely run out of VRAM on my scenes and I will be upgrading to NVlink and RTX soon, I don't care much about OOC
If I ever run out of VRAM, I can use the Cuda engine in CPU mode, which also works on Chaos Cloud. Or from the start, I would be using Vray CPU(which has a lot more features than Vray GPU)

Thanks for stating this in a way i couldn't.
My experience with every other implementation of OOC has been very similar, so OOC comes into play for GPU engines as an extreme ratio alternative to crashing the video driver.
We fortunately (wisely? :P) have alternatives which would provide for a better overall experience, and quicker time to finished render (as mentioned by Muhammed).

[Muhammed_Hamed]

Redshift and Octane doesn't have Hybird rendering or a CPU option like V-ray.. OOC would make sense there as rendering at slower speed is better than not being able to render
Also OOC can make things unstable, it is probably the most overrated thing about GPU rendering on the internet.
For V-ray, this is quite different, there are better alternatives to OOC.. and considering the other facts above, it was surprising that Chaos invested a lot into OOC.. they have been working on it for over a year so far
I cannot judge until this is released and tested, maybe it can be better than other renderers at this.. who knows