If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Exciting News: Chaos acquires EvolveLAB = AI-Powered Design.
To learn more, please visit this page!
New! You can now log in to the forums with your chaos.com account as well as your forum account.
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.
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.
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?
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.
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.
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.
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
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.
Leave a comment: