GPU benchmarks

[chriserskine]

ok well that was successful.

updated drivers, and removed the sli bridge.

now both cards are running at 1850mhz +

thanks for your help.

[Donfarese]

Cool buddy, have fun.

[CRD]

chriserksine - have you run the benchmark 2.0 with your 1080? Can you run it with a single card and then with both cards?

I'd still like to verify if my 18 minute time with VRay 3.4 is similar to other 1080's.

Thanks

[chriserskine]

I haven't had a chance to run any benchmarks yet.

I'm also still on vray 3.3.

I plan on upgrading that in a couple of weeks. so I'll see if i can run it then.

[Sushidelic]

chriserksine - have you run the benchmark 2.0 with your 1080? Can you run it with a single card and then with both cards?

I'd still like to verify if my 18 minute time with VRay 3.4 is similar to other 1080's.

Thanks

We've been running the 2.0 Benchmark on Vray 3.40.02 on 9x GTX 1080, which took 2.06 minutes. Assuming it scales close to linear, that would average out to 18.9 minutes on a single card.

Best regards, Michael

[Sbrusse]

Yeah I'm guessing SP4 interpret noise differently because on my 7 Titan X OCed I was getting 1min 33 so you should be at least as fast if not a pinch faster

[savage309]

Yeah I'm guessing SP4 interpret noise differently

That is correct.

Best,
Blago.

[Sushidelic]

Out of curiosity I ran the benchmark with V-Ray RT 3.20.03 and Nvidia 3.68.39, and got 1m 17s out of the 9x GTX 1080, and the result didn't differ much from the latest version visually. But what was the more astonishing part is, that the rendering started way quicker.
With 3.40.02 it takes something like 1:30m on first start (ages!), to initialize cuda for all devices, and around a minute to start rendering. On every subsequent start, it only takes this one minute to start (still quite some time, if you consider that all 9 GTX run at 8x PCI-E 3.0 in one machine).
With 3.20.03, those times were also aproximately half as long. I would actually need to measure that exactly, but it seemed a lot faster.

Is there any way to make the initialization for multiple GPU setups faster? When it's rendering, it's blazing fast, but the waiting period in the beginning can be quite annoying.

[savage309]

THe first time you run V-Ray GPU it compiles some shaders for your GPUs. Those are cached and are not recompiled the next time you start it. I believe start up time could be optimized further as well.

Best,
Blago.

[super gnu]

a not-strictly-legit result, but using LC and the new irradaince map from file in the beta, i got approx 40- 50 seconds for benchmark 2 on a single titan x.

i say approximate because due to (i assume) a beta bug, it continues rendering past the paths/pixel limit of 2048, and jumped from 64 paths to 3600+ at around 58 secs. it didnt appear to be interface lag, i had a spare gpu doing the interface stuff.


i left it going, it got to well over 7000 paths, so its not just a small discrepancy, seems it was gonna carry on forever.

[danio]

a not-strictly-legit result, but using LC and the new irradaince map from file in the beta, i got approx 40- 50 seconds for benchmark 2 on a single titan x.

i say approximate because due to (i assume) a beta bug, it continues rendering past the paths/pixel limit of 2048, and jumped from 64 paths to 3600+ at around 58 secs. it didnt appear to be interface lag, i had a spare gpu doing the interface stuff.


i left it going, it got to well over 7000 paths, so its not just a small discrepancy, seems it was gonna carry on forever.

Wow! So, am I confused or is that...more than 10x faster than BF\BF? How does it look?

[super gnu]

it looks fine, like a normal irmap/lc render. not as sharp as bf, but it all depends on the imap. obvs that does not include the imap calc time, but for a flythrough, with a precalced multiframe incremental imap, its an awesome result.

[vlado]

i left it going, it got to well over 7000 paths, so its not just a small discrepancy, seems it was gonna carry on forever.

It only seems so; eventually it will complete when all pixels that need sampling have been finished. Sometimes pixels may be (re)activated later on in the rendering if something changes around them.

Best regards,
Vlado

[super gnu]

It only seems so; eventually it will complete when all pixels that need sampling have been finished. Sometimes pixels may be (re)activated later on in the rendering if something changes around them.

Best regards,
Vlado

hm, in that case im getting much longer benchmark times with the new beta.. i got 4m 11 secs on my oc titan x before.. but with the beta it was over 6 minutes when i cancelled it.


-EDIT.. im being an idiot.. im confusing benchmarks 1 and 2... i got 8 minutes something on my oc titan x .. doh.

[savage309]

i got 8 minutes something on my oc titan x .. doh.

The better way to compare is to let it render for the same amount of time and compare the noise in the results. The image sampler can take different decisions for when a certain noise is reached - depending on the dynamic noise threshold, max samples per pixel, etc.

Best,
Blago.