[Bf-cycles] Fwd: re: Render tiles in GPU

Cal McGaugh cal at cal3d.com
Sun Nov 11 05:58:25 CET 2012


sorry, wrong link......here it is!
http://blenderartists.org/forum/showthread.php?271988-Tile-Settings-for-Fastest-Cycles-GPU-Renders
<http://blenderartists.org/forum/showthread.php?271988-Tile-Settings-for-Fastest-Cycles-GPU-Renders>

Thanks,
Cal




---------- Original Message ----------
From: Cal McGaugh <cal at cal3d.com>
To: bf-cycles at blender.org
Date: November 10, 2012 at 12:15 AM
Subject: Re: [Bf-cycles] Render tiles in GPU vs CPU
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 <mailto: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 <http://patazstudio.com>
> > 
> > 
> > 
> >    On Wed, Nov 7, 2012 at 6:15 PM, Cal McGaugh <cal at cal3d.com
> > <mailto: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 <mailto: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 <mailto:Bf-cycles at blender.org>
> > > >       http://lists.blender.org/mailman/listinfo/bf-cycles
> > > > <http://lists.blender.org/mailman/listinfo/bf-cycles>
> > > > 
> > > >      > > > 
> > > 
> > >      _______________________________________________
> > >      Bf-cycles mailing list
> > >      Bf-cycles at blender.org <mailto:Bf-cycles at blender.org>
> > >      http://lists.blender.org/mailman/listinfo/bf-cycles
> > > <http://lists.blender.org/mailman/listinfo/bf-cycles>
> > >    > > 
> >    _______________________________________________
> >    Bf-cycles mailing list
> >    Bf-cycles at blender.org <mailto:Bf-cycles at blender.org>
> >    http://lists.blender.org/mailman/listinfo/bf-cycles
> > <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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20121110/3f1b16b8/attachment.htm 


More information about the Bf-cycles mailing list