Hi all,

Just to say that I am experimenting with rendering an animation using a RAMDISK
(M$ iscsi virtual harddisk on 2012 R2 on RAM)

Will export continuously the output to another HDD directory with robocopy.

Thought that it would be a nice stepping stone for the implementation of bitcode
rendering (don't remember if it is the official computing term of a differential
re-parse)

Will use a 43K (700 MB tga) for image_map and a max resolution output for file.
The storage of the povstate in RAM should give the performance a big boost.

Devteam, do you see any possible catches with that RAMdisk tech ?

Will keep updated probably after 17 april.

A+

Rod.

Post a reply to this message

"rodv92" <nomail@nomail> wrote:
> Hi all,
>
> Just to say that I am experimenting with rendering an animation using a RAMDISK
> (M$ iscsi virtual harddisk on 2012 R2 on RAM)
>
> Will export continuously the output to another HDD directory with robocopy.
>
> Thought that it would be a nice stepping stone for the implementation of bitcode
> rendering (don't remember if it is the official computing term of a differential
> re-parse)
>
> Will use a 43K (700 MB tga) for image_map and a max resolution output for file.
> The storage of the povstate in RAM should give the performance a big boost.
>
> Devteam, do you see any possible catches with that RAMdisk tech ?
>
> Will keep updated probably after 17 april.
>
> A+
>
> Rod.

typo : directory

Post a reply to this message

> Hi all,
>
> Just to say that I am experimenting with rendering an animation using a RAMDISK
> (M$ iscsi virtual harddisk on 2012 R2 on RAM)
>
> Will export continuously the output to another HDD directory with robocopy.
>
> Thought that it would be a nice stepping stone for the implementation of bitcode
> rendering (don't remember if it is the official computing term of a differential
> re-parse)
>
> Will use a 43K (700 MB tga) for image_map and a max resolution output for file.
> The storage of the povstate in RAM should give the performance a big boost.
>
> Devteam, do you see any possible catches with that RAMdisk tech ?
>
> Will keep updated probably after 17 april.
>
> A+
>
> Rod.
>

The *.povstate file is only needed if you want to be able to stop, then 
resume, a render. In the latest beta, it's possible to disable it. The 
drawback is that an interupted render can't be resumed.

If you disable the continue feature by disabling the *.povstate file, 
the only write operation is that of the completed image as a .PNG file 
after the end of the render.

If you have enough RAM to prevent POV-Ray from needing to use the 
virtual memory, I don't think that using a RAM drive will have a large, 
or even significant, impact on the performance.

The presence of the RAM drive will reduce the available RAM. This may 
cause the internal storage to exceed the available RAM, forcing it to be 
stored on disk. In this case, the overhead of accessing your RAM disk 
can actually impair your performance and cause your render to take longer.

Post a reply to this message

Alain <kua### [at] videotronca> wrote:

> > Hi all,
> >
> > Just to say that I am experimenting with rendering an animation using a RAMDISK
> > (M$ iscsi virtual harddisk on 2012 R2 on RAM)
> >
> > Will export continuously the output to another HDD directory with robocopy.
> >
> > Thought that it would be a nice stepping stone for the implementation of bitcode
> > rendering (don't remember if it is the official computing term of a differential
> > re-parse)
> >
> > Will use a 43K (700 MB tga) for image_map and a max resolution output for file.
> > The storage of the povstate in RAM should give the performance a big boost.
> >
> > Devteam, do you see any possible catches with that RAMdisk tech ?
> >
> > Will keep updated probably after 17 april.
> >
> > A+
> >
> > Rod.
> >
>
> The *.povstate file is only needed if you want to be able to stop, then
> resume, a render. In the latest beta, it's possible to disable it. The
> drawback is that an interupted render can't be resumed.

For the records: Disabling the state file is achieved by specifying `-CC` or
`Create_Continue_Trace_Log=no`.

Post a reply to this message

Alain <kua### [at] videotronca> wrote:

> > Hi all,
> >
> > Just to say that I am experimenting with rendering an animation using a RAMDISK
> > (M$ iscsi virtual harddisk on 2012 R2 on RAM)
> >
> > Will export continuously the output to another HDD directory with robocopy.
> >
> > Thought that it would be a nice stepping stone for the implementation of bitcode
> > rendering (don't remember if it is the official computing term of a differential
> > re-parse)
> >
> > Will use a 43K (700 MB tga) for image_map and a max resolution output for file.
> > The storage of the povstate in RAM should give the performance a big boost.
> >
> > Devteam, do you see any possible catches with that RAMdisk tech ?
> >
> > Will keep updated probably after 17 april.
> >
> > A+
> >
> > Rod.
> >
>
> The *.povstate file is only needed if you want to be able to stop, then
> resume, a render. In the latest beta, it's possible to disable it. The
> drawback is that an interupted render can't be resumed.
>
> If you disable the continue feature by disabling the *.povstate file,
> the only write operation is that of the completed image as a .PNG file
> after the end of the render.
>
> If you have enough RAM to prevent POV-Ray from needing to use the
> virtual memory, I don't think that using a RAM drive will have a large,
> or even significant, impact on the performance.
>
> The presence of the RAM drive will reduce the available RAM. This may
> cause the internal storage to exceed the available RAM, forcing it to be
> stored on disk. In this case, the overhead of accessing your RAM disk
> can actually impair your performance and cause your render to take longer.

Thanks for all the input, I figured that my idea was a bit silly after some time
too.

And yes, the results are very modest indeed 1.5 percent gain. (on 4 frames of an
animation that takes 45 seconds parse time per frame)
And since the TGA is alredy loaded in RAM between renders, i only see the
possibility of gaining time in the saving of the PNG, which is ridiculously
insignifiant, and since you have to copy to the hard disk at some time, it makes
no sense at all.
It could be of help only if your disk IO is very low and you have plenty of RAM.
And basically, The same results could be obtained by enabling a write-back disk
cache, I think.

Post a reply to this message