Thorsten Froehlich <tho### [at] trfde> wrote:
> Andycadd wrote:
> > Disk buffering  .....  that is working in 3.6 currently?
>
> There is no "disk buffering". What POV-Ray 3.6 and earlier do is write the
> file to disk line by line. While POV-Ray 3.7 also writes the file in a
> temporary format to disk to support a continue trace in case of a crash, it
> further keeps a whole copy in memory as it will now write the final image to
> disk at the end of the render, rather than write it incrementally and
> (mis)use it as continue trace buffer like 3.6 and earlier did.
>
> The problem with using any fixed image format for continue trace in 3.6 and
> earlier is that image formats do not actually store all the information
> necessary to properly continue a trace, in particular with anti-aliasing
> enabled. Hence this problem has been addressed in 3.7.
>
> > How come the windows virtual memory doesn't just pick this up?
> > PLEASE excuse my ignorance.
>
> Because you still only have 2 GB to 3GB (depending on Windows version) of
> address space for a 32 bit application.
>
>  Thorsten


Is there an option to not keep a full copy in memory (freeing up that 320MB
mentioned above) with or without a running display ?  I know this would be a
speed hit but Rambus memory ain't cheap.  Or maybe just keep the previous
row in memory and flush the extra?

Post a reply to this message

Andycadd wrote:
> Is there an option to not keep a full copy in memory (freeing up that 320MB
> mentioned above) with or without a running display ?  I know this would be a
> speed hit but Rambus memory ain't cheap.  Or maybe just keep the previous
> row in memory and flush the extra?

Ben Chambers wrote:
> If it's really a problem with memory addressing, as you seem to be
> suggesting, perhaps a more suitable error message could be introduced?

As I said before: "disk buffering has not been implemented yet."  So this
issue will go away really "soon"...

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Andycadd wrote:
> > Is there an option to not keep a full copy in memory (freeing up that 320MB
> > mentioned above) with or without a running display ?  I know this would be a
> > speed hit but Rambus memory ain't cheap.  Or maybe just keep the previous
> > row in memory and flush the extra?
>
> Ben Chambers wrote:
> > If it's really a problem with memory addressing, as you seem to be
> > suggesting, perhaps a more suitable error message could be introduced?
>
> As I said before: "disk buffering has not been implemented yet."  So this
> issue will go away really "soon"...
>
>  Thorsten

Sorry bout that I misread to be clear I love the SMP features makes my Dual
2.4 Xeons useful again.  I also own an older Quad Xeon w/1MBcache EA proc
does the SMP feature use all 4 procs?  They are only 550Mhz ea but big
cache size could help. should I put it back together?

Post a reply to this message

Andycadd <And### [at] comcastnet> wrote:
> does the SMP feature use all 4 procs?

  That's a strange question, don't you think?

-- 
                                                          - Warp

Post a reply to this message