Le_Forgeron <jgr### [at] freefr> wrote:
> I'm on something : a.resize(-1) in previous code (previous message) lead to:
>
> terminate called after throwing an instance of 'std::length_error'
>   what():  vector::_M_fill_insert
> Abandon (core dumped)
>
>
> Looks like vector does not like negative resize (due to promoting int(32
> bits) to size_t after computation)

Wow! I did not expect someone to dig as deeply into this as you have, but thank
you very much. It looks like it is pretty clear at this point that the 41K x 41K
image is going to be beyond the capabilities for a little while at least. I will
just have to come up with a way to efficiently break the image into smaller
segments and recombine them although that is definitely sub-optimal.

Thanks for the information.

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Nice, but I suppose you are running a 32 bit Windows XP on it? That means 
> you have a maximum of 2 GB (default, or 3 GB with a XP boot option) per 
> process of memory available. A 41000*41000 24 bit image already consumes 4.7 
> GB of memory, which a 32 bit system cannot handle. You need to use a 64 bit 
> Windows with the 64 bit version of POV-Ray.

  IIRC at least older versions of POV-Ray were designed such that, if you
were not using image preview, it would just stream the resulting image to
the output file rather than keeping it all in memory, and hence the only
limitation to image size is the maximum image size supported by the image
file format (and file system).

  Does the current version of POV-Ray require for the entire image to be
kept in memory?

-- 
                                                          - Warp

Post a reply to this message

On 09/29/2010 06:54 PM, Thorsten Froehlich wrote:

> Nice, but I suppose you are running a 32 bit Windows XP on it? That
> means you have a maximum of 2 GB (default, or 3 GB with a XP boot
> option) per process of memory available. A 41000*41000 24 bit image
> already consumes 4.7 GB of memory, which a 32 bit system cannot handle.

    Did you mean that POVray keep the full generated picture in memory
    when rendering it ?

Post a reply to this message

On 1/10/2010 02:25, tth wrote:
> Did you mean that POVray keep the full generated picture in memory
> when rendering it ?

Generally, yes. This is not optimal for huge renders, but for the types of
ones most users do it's an optimization that increases speed. Keep in mind
that as the SMP version of POV-Ray can render portions of the image out of
sequential order, it would complicate the image code quite a bit if we had
to be able to create the image in advance and then read and write any
arbitrary block (this is doubly so for files that use compression), and
would have a performance impact due to all the disk I/O.

We could cache the data to an intermediate file in raw format (and in fact
there is some code in there for this, however it's not currently working
properly), but while that bypasses the issue of the image file format, it
still leaves us with the I/O penalty.

Ideally we'd have an INI option to tell POV when to stop using RAM and
start using disk for the temporary image cache, however at this point there
is no setting for it.

-- Chris

Post a reply to this message

Le 30/09/2010 09:42, Chris Cason nous fit lire :
> On 30/09/2010 03:41, Le_Forgeron wrote:
>> I'm on something : a.resize(-1) in previous code (previous message) lead to:
>>
>> terminate called after throwing an instance of 'std::length_error'
>>   what():  vector::_M_fill_insert
>> Abandon (core dumped)
>>
>>
>> Looks like vector does not like negative resize (due to promoting int(32
>> bits) to size_t after computation)
> 
> Thanks for tracking this down - please feel free to raise a bug on it.

Your wish is my command, even if I prefer to see the bugs getting closed
than opened. (hint: #64 might get some progress)

I just took time to reduce the original size to still produce the bug
and yet keep it in memory (swap is crawling).

It won't be for the faint hearted: a 30500 x 30500 does still produces
the bug, but you'd better have 24 GB of true ram to test it.

Post a reply to this message

On 09/30/2010 06:44 PM, Chris Cason wrote:
> On 1/10/2010 02:25, tth wrote:
>> Did you mean that POVray keep the full generated picture in memory
>> when rendering it ?
>
> Generally, yes.

    This was not the case for 3.6.1 ?

Post a reply to this message

tth <tth### [at] noneinvalid> wrote:
> On 09/30/2010 06:44 PM, Chris Cason wrote:
> > On 1/10/2010 02:25, tth wrote:
> >> Did you mean that POVray keep the full generated picture in memory
> >> when rendering it ?
> >
> > Generally, yes.
>
>     This was not the case for 3.6.1 ?

I still use 3.6.1 and I tried it with 41000x41000 pixels. I used: +fn
display=off  in the command line and it seems to be rendering OK, the image is
written right away on the hard disk.
I have quite an old computer with only 2 GB of RAM. I haven't had the patience
to wait until this test image was finished though, but I didn't get any error
messages or whatever, so I guess it works fine.

I don't know about version 3.7, is it not possible to switch of the display
anymore in that version?

Best wishes,

Simone

Post a reply to this message

On 10/04/2010 04:07 PM, Simone wrote:
> I don't know about version 3.7, is it not possible to switch of the display
> anymore in that version?

the -d option works like it always has ;-)

Post a reply to this message

Jim Holsenback <jho### [at] povrayorg> wrote:
> On 10/04/2010 04:07 PM, Simone wrote:
> > I don't know about version 3.7, is it not possible to switch of the display
> > anymore in that version?
>
> the -d option works like it always has ;-)


Uhm, I'm a little confused now.
In 3.6 I used to get an error with large images which said "failed to allocate
display bitmap" but with -d it worked fine.

But if the -d option works the same in 3.7 I wonder why there was the problem
with the large image fillibar wrote about in the first message?

Or does it mean that the display can be switched of with -d in 3.7 but still
needs all the memory for the display (unlike version 3.6)? But I thought the
main reason for switching off the display was to save memory (at least I can't
imagine another reason to use it.)

Best wishes,

Simone

Post a reply to this message

On 10/04/2010 08:46 PM, Simone wrote:
> Jim Holsenback <jho### [at] povrayorg> wrote:
>> On 10/04/2010 04:07 PM, Simone wrote:
>>> I don't know about version 3.7, is it not possible to switch of the display
>>> anymore in that version?
>>
>> the -d option works like it always has ;-)
> 
> 
> Uhm, I'm a little confused now.
> In 3.6 I used to get an error with large images which said "failed to allocate
> display bitmap" but with -d it worked fine.

didn't you mention in an earlier post using display=off ... same as -d

> But if the -d option works the same in 3.7 I wonder why there was the problem
> with the large image fillibar wrote about in the first message?
> 

look back several posts by Le Forgeron in this thread ...

> Or does it mean that the display can be switched of with -d in 3.7 but still
> needs all the memory for the display (unlike version 3.6)? But I thought the
> main reason for switching off the display was to save memory (at least I can't
> imagine another reason to use it.)

I don't think that's changed ... one of the devs that knows more about
the core could answer that for sure

Post a reply to this message