[Bf-cycles] Render tiles in GPU vs CPU
Daniel Salazar - 3Developer.com
zanqdo at gmail.com
Sat Nov 10 21:34:41 CET 2012
Oh yeah this is a public board, go ahead
Daniel Salazar
patazstudio.com
On Fri, Nov 9, 2012 at 11:15 PM, Cal McGaugh <cal at cal3d.com> wrote:
> **
> Hi Sergey, Daniel, Adriano,
>
> I would like to start a thread at Blenderartists.org "Setup Cycles for
> Fastest GPU Renders"
> and ask for your permission(s) to quote you from this email.....or if you
> would rather not
> be quoted, at least to use the info.
>
> I'm just trying to help users (& myself) understand what the variables
> are, and how to get the best render times
> depending on whether using the CPU or GPU.......what is the best tile
> size (or pixel resolution), when to use progressive vs tiles, etc.
>
> Maybe it would generate a lot of useful data from other users.
>
> The bench marks are almost irrelevant.....i.e. there doesn't seem to be a
> good correlation between CUDA cores and render times.
> The NVIDIA 500 series has fewer cores than the 600's but so far seem to
> be faster.
>
> I hadn't considered trying different tile size until Adriano replied to
> my first email to try 1x1, which did help. But now it appears
> that one size doesn't fit all, and each user may have to experiment to
> find the best for their system configuration.
>
> BTW, I'm also going to try out Blenderbuntu on a small SSD (32gb) to see
> if I can get even faster renders, and will post
> results if that works well.
>
> Do we know if 2.64 renders slower than 2.63 due to tile settings alone or
> is there something in the code?
> I saw a post that speculated it might be due to all the new things added
> to 2.64(?)
>
> Below are some tests I ran just to see how fast it rendered vs 2.63 and
> was very surprised to see such
> a discrepancy.....I expected to see similar times, if not faster renders,
> especially for the Fastest Cuda (all cores) Blender.
>
> The first column are the times (min:sec) for this benchmark<http://benchmark.cd3dtech.com/Benchmark/benchmark.html> and
> column 2 values are for Mike Pan's benchmark.<http://blenderartists.org/forum/showthread.php?239480-2-61-Cycles-render-benchmark&highlight=benchmark>
> Regardless of the tile settings, the times are consistently longer for
> 2.64. (EVGA GTX460 2GB)
>
>
> 2.63a r46461:46487M 6:22 1:13
>
> "Fastest CUDA" r51640 8:15 1:37
>
> Blender.org 2.64a r51232 8:08 2:01
>
> Buildbot.com r51641 8:16 1:37
>
> I just downloaded the latest official release and the latest "Fastest"
> and will try different tile settings to see what
> is best for my system using the info here.
>
> Also upgraded to a Zotac GTX580 since I did the tests above, and it
> renders ~1.7x faster than the 460.
>
> Is this list just for developers or is it open to anyone who is
> interested in Cycles?
>
> Thanks,
> Cal McGaugh
>
>
>
>
>
>
>
>
>
> On November 8, 2012 at 3:29 AM Sergey Sharybin <sergey.vfx at gmail.com>
> wrote:
>
> This is a bit more complicated issue. Performance on GPU is not only
> depends on number of tiles, but also on particular size of tile. Making
> tiles size aligned to 16 pixels made much sense when i was doing tests
> during Mango. SO i could think using tile size of 1024x1024 could end up in
> faster render than using single tile for HD frame.
>
> Also, as Daniel already mentioned, you could easier run out of memory
> with single tile and to make it more control over performance in such cases
> pixel-based tile size makes more sense.
>
> If you want to force single tile being used always, why don't set tile
> size to 10K by 10K pixels -- it'll be clamped to actual image internally in
> render engine :)
>
>
> On Thu, Nov 8, 2012 at 6:37 AM, Daniel Salazar - 3Developer.com <
> zanqdo at gmail.com> wrote:
>
> Speed is only half of the issue here. An HD (or higher) render will take a
> lot of memory and can very well crash your GPU rendering if not using
> tiles. What works for a couple models is not what works for a complete
> scene!
>
> Daniel Salazar
> patazstudio.com
>
>
>
> On Wed, Nov 7, 2012 at 6:15 PM, Cal McGaugh <cal at cal3d.com> wrote:
>
> Hi Adriano,
> very interesting..........no wonder I'm seeing longer renders with 2.64
> vs 2.63.
>
> Will do more tests with different versions. Just got a new (used) Zotac
> GTX580
> and will test different tile settings.
>
> Thanks,
> Cal
>
>
>
>
> On November 7, 2012 at 7:02 PM Adriano Oliveira < adriano.ufrb at gmail.com>
> wrote:
>
> Hi,
>
> Subdividing render image in tiles has very inconsistent behavior in CPU
> and GPU: more tiles are good for CPU, BUT less are better for GPU.
>
> With my i7, 8x8 is ok. With my GTX 560 Ti, 1x1 is the best. With another
> dual GTX 590 system, I've found 3x3 to be fastest...
>
> Problem: with 8x8 as default, non-advised GPU users are experiencing
> longer render times.
>
> In last builds, tiles became pixel based, what is not good for GPU users,
> as long as we should now set it up for equal image size and this can change
> a lot for preview. And as strange as it gets, I’ve found that tile size of
> 1920x1080 is fast even for a 960x540 render…
>
>
>
> I think this is getting messy.
>
>
> Adriano A. Oliveira
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
>
>
> --
> With best regards, Sergey Sharybin
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20121110/7cecb336/attachment.htm
More information about the Bf-cycles
mailing list