using a miner station for rendering.

For testing I temporally got a miner station out of 7 AMD 480gtx.
So far the processor is not optimized just 2 cores i3 not a i7. (will test i7 tomorrow)
Its windows 10, latest AMD drivers, slightly over-clocked.
There is something that makes me wonder about this setup.

If i do for example the BMW scene it takes 47 sec, another project of mine takes about 1:05 minutes.
The same frame in renderstreet goes in about 25 secconds.

Well to me its clear that CPU is the bottle neck now.
As 70% of the time is spend on CPU to create bhv, then the GPU’s kick in, and they require another 25% of total render time. When the GPU’s are busy the CPU usage is very low.
And when the CPU is used the GPU usage is like 0% (fans go out).
I’m using auto-tile addon, and official 2.79 (and also used other 7.79 versions, the daily build and the fastest build).

As far as i understand Blender is fast, but I got a feeling that this setup should be able to perform faster.
So I wonder is it normal for Blender that if the GPU’s are busy the CPU doesn’t start working bhv stuff on the next frame? (while keeping an eye/thread open to the progress of the GPU’s ?).

Or should I run it command line, width some options to render an animation faster ?.

your experience sounds about right

single frame render time increases with increased number of gpus/nodes used (since compiling is done for every unit separately) - especially noticeable on simple scenes / there’s an optimum between complexity VS which & how many units to use (considering not all units are efficient equally)

you can optimize for animation rendering by dividing the number of frames by the number of computing units & distribute according to their efficiency

if anyone is up for making calculator/configurator/addon, that would be great - something along the line of farm management

Moved from “General Forums > Blender and CG Discussions” to “Support > Lighting and Rendering”

Sounds as if something could be optimized in CPU threading here, if what you say is true, i cannot verify it.
But its the end of 2.7x series now, so it might never happen.
It might have some big impact for renderfarms, if GPU’s indeed wait on CPU.
If the BHV pre-processing could start earlier it would allow them to make more use of their GPU’s.

I’ve never dived into Blender’s threading, but i often use multi threaded code in my work.
Its quite common to have different queues, for different tasks. I think Blender uses openMP, and that allows for setting priorities, ea 1 high prio thread monitors a queue of gpu tiles, while the rest of the cpu threads would start doing bhv.

Most of the new multithreading code uses a custom API made just for Blender (due to weaknesses and other issues with pre-built solutions like OpenMP).

I’m not sure if the same applies to Cycles though.

@Ace if that is so, might they be interested in a bug report then ?, (technically it works, but then multi threading isnt optimal).

@Burnin, you mean a script that renders whole frames per GPU… hm i dont know the more cards i added the faster it went, 7 cards while an odd number still was faster then 6 cards (to my suprice), the autotilesize addon worked well.
Though because the CPU requires 70 of the time and the GPU’s 30% the cpu wouldnt be able to fill the gpu information in time.
I could take out 4 cards, but that would decrease the speed also a lot.

Well i post an update if the i7 arrives today.

well the I7 arrived broken, and i wont spend another 300 dollar for it.
So i just keep the trick in my mind to disable split bhv.

OH and also maybe interesting, i tested width more and less GPU cards.
At one moment it had 12 GPU’s, but i think beyond 6 there is point where additional cards dont add much on the same PC, its better then to add another PC; the reason the tile size get smaller reducing effective usage of GPU’s