Render Eevee animations N times faster

Just a quick observation; this may well be common knowledge, in which case- ignore me or tell me to shut up!..

I render using .bat files (Windows) when I do animations: 2 workstations and a reasonable laptop- so not really worth calling it, or treating it as a render farm! Nevertheless it’s well useful for rendering out multiple scenes / passes, just for a flexible render queue.

Anyway, while rendering out one such scene which was using Eevee as the render engine I noticed in ‘Task Manager’ that only one GPU was chugging away at 90-100%, the other two were doing stuff-all.
Then I remembered seeing the ‘Render OpenGL’ option in the right click menu when running a .bat file so I tried it- all 3 GPUs on my workstation happily working at 80-90%, for the same render time as one GPU (and both GPUs on my old workstation as well)…

(Might only be an option in Windows10 Pro, my laptop does not show ‘render OpenGL on…’ menu option, but it only has one GPU so maybe not…)
RenderOpenGL

First time I’ve tried this, so I wouldn’t say it’s 100% tried-n-tested, but it worked like a charm!
Anyone else use this / know this?..

4 Likes

I don’t think this is common knowledge and great to see you’re benefiting from multiple GPUs when rendering in Eevee.

Could you please tell more about that .bat file and how can we set up such thing? (Consider i have little knowledge with coding)

Here you go- https://www.youtube.com/watch?time_continue=55&v=WBaFvhPhIZw

That’s the vid I watched to learn how. And i use a package called ‘Tight VNC’ to control the machines I am not connected to keyboard / mouse wise, to start things going and keep an eye on things.

Re the above: I did another Eevee render last night, and it seems that my old HP z800 is completely rock solid at using both GPUs, while my new AMD box with 3 GPUs was somewhat less solid.
It was a 600 frame animation and both DOS / Shell processes on the z800 went through the whole thing without a hiccup. While on the AMD machine each GPU process died once, with the primary / display GPU process dying twice.
In fairness the AMD AM4/Threadripper is quite a new box and may well settle down with subsequent motherboard drivers. And while the z800 has a matching pair of ASUS GTX970 cards- the AMD box has two slightly different Gigabyte GTX1070s and one Zotac GTX1070ti, which might be why it doesn’t work as solidly.
Regardless- I still rendered the 600 frames of HD in about 30 minutes or so, despite having to re-start the AMD box’s processes after deleting the placeholder files the dead processes left behind. I’m fairly sure it would have taken a good hour plus for the render, without this trick.

And this one process per GPU trick only works for Eevee renders.

You can get some extra speed with Cycles renders (I mainly use CPU+GPU if I can as it’s quicker and uses the hardware more), but it’s somewhat less exact.
Here the AMD box wins hands down over the old z800, which could be the extra third GPU or more & faster cores (or that the AMD is one 16 core CPU, not two 6 core CPUs for that matter).
It is very scene dependent with cycles; basically if you can manage to run 2 processes and get one rendering tiles, while the other is loading/synchronising/packing BVH nodes etc. it works- and you get 2 frames for 10-30% slower than single process per machine frames.
If however, both processes get to the ‘rendering tiles’ bit at the same time the render slows down quite a lot, this is way more noticeable on my z800 than on the AMD- which just seems to power through and only overlaps for the first/last 10-20 tiles never seeming to get less than 2 frames for 10-30% slowdown per frame.

Basically if you have quite a few CPU cores and more than one GPU per machine, give it a go and compare overall render times. But for cycles you want a scene that takes at least 30-50% of the render time per frame loading, before the ‘rendering tiles’ bit happens.
So for example the last Cycles scene I rendered this way was a couple of particle systems as snow, so 20 odd seconds per frame on the fastest (AMD) machine and about a minute or so on the slowest (z800). A good 40% of the frame render time was the render process loading/packing/synchronising etc.
If you have long render time scenes I would not bother- Cycles uses most GPU + CPU horsepower when it’s rendering (80-90% on my AMD), so on long render time scenes more than one process will slow things down, not make things quicker.

I think the specific solution you have found is Nvidia GPU specific, driven by their driver. I haven’t seen this option with My RX Vega’s. So when I render only 1 GPU is used while other is just idling :frowning:

If I missed something, and you indeed had it running on AMD GPU’s please tell

No, all Nvidia, it could well be a driver added menu item (‘run OpenGL on’ etc.).
It might be worth asking if there are command line arguments you could add to the .bat file to force it onto a particular GPU when it is run. But that’s beyond me!..
Or ask AMD why their driver does not offer what Nvidia’s does!

I assume if you just run the process twice it tries to use one GPU for both jobs, which I just tried and is what happens if I do this.

I’d definitely start poking AMD about why their drivers aren’t as good as Nvidia’s!.. (this is an Nvidia driver feature, I just googled it)

Edit
I just found this- tenforums.com/tutorials/103965-set-preferred-gpu-apps-windows-10-a.html
You might be able to trick it that way, but I’d guess you would need 2 blender installations, and 2 different .bat files pointing to the individual blender.exe files - so quite a bit of a ball-ache to do!

But then again- I currently have Blender installed 4 times on my machines:
Vanilla 2.79, for stuff that won’t work in 2.8 properly yet.
Vanilla 2.8, for most things.
Fracture Modifier 2.79, for itself.
And 2.81 beta, primarily for the holdout shader working in Eevee (so far)…

1 Like