When i try to render a scene in version 3.6.1 it works.

When i try to render the same scene using 3.7 beta 41 the render will abort
about half way through with the message "Internal limit exceeded in
FixedSimpleVector"

I am running this on the 64 bit version of fedora 14.

What causes this error?

Are there any workarounds?

Could the error message be rewritten to indicate which object(s) are causing the
problem?

Thank you

Richard

Post a reply to this message

Am 27.12.2010 18:40, schrieb RM:
> When i try to render a scene in version 3.6.1 it works.
>
> When i try to render the same scene using 3.7 beta 41 the render will abort
> about half way through with the message "Internal limit exceeded in
> FixedSimpleVector"
>
> I am running this on the 64 bit version of fedora 14.
>
> What causes this error?

You are hitting the currently hard coded limit of 127 light sources in 
the workaround code of file backend\interior\media.cpp (lines 695 and 696).

> Are there any workarounds?

1. You could raise the hard coded limit in the above lines and recompile
2. or (preferred) you could fix the code beginning at line 727, so we 
don't need the workaround code with hard coded limits anymore.

> Could the error message be rewritten to indicate which object(s) are causing the
> problem?

Too many light sources are triggering this. It will probably not be 
rewritten, since it is only "workaround code".

Happy new year,
hexcoder

Post a reply to this message

Am 03.01.2011 10:15, schrieb Hexcoder:
> Am 27.12.2010 18:40, schrieb RM:
>> When i try to render the same scene using 3.7 beta 41 the render will
>> abort
>> about half way through with the message "Internal limit exceeded in
>> FixedSimpleVector"

>> What causes this error?
>
> You are hitting the currently hard coded limit of 127 light sources in
> the workaround code of file backend\interior\media.cpp (lines 695 and 696).
>
>> Are there any workarounds?
>
> 1. You could raise the hard coded limit in the above lines and recompile

Oops, that is not enough. There are more than those places to change.
backend\render\trace.h has some uses of FixedSimpleVector, as has
backend\frame.h

I changed all of them from 127 to 255 entries, which worked for me.

---

A simple enhancement would be to use one constant for all those 
container sizes, so the hard coded constant need to be changed only in 
one place.

I would "fix" the code if I only understood the intentions of the 
authors here fully.

The second step would be to get rid of hard coded limits where possible.

Then get rid of all remaining TODO/FIXMEs...

Thanks, hexcoder

Post a reply to this message

On 3/01/2011 22:34, Hexcoder wrote:
> The second step would be to get rid of hard coded limits where possible.

In the case of FixedSimpleVector, that's more difficult than it seems. The
hard-coded limit is needed because that class is explicitly designed to use
stack for storage, rather than the heap, which thus means the compiler
needs to know its size at build time.

This avoids the need to do heap allocation/frees (with the associated
locking), or re-sizes as the vector grows (which often, though not always,
requires a memcpy).

FixedSimpleVector is only used in places where either of those have a
drastic effect on performance. Going to a dynamic version of those classes
would require the use of a thread-local memory pool and smart management of
the amount of memory pre-allocated for the vector each time it's
instantiated (or analysis of the code that depends on it to see where we
can switch from using a vector to a list).

Also keep in mind that each time you increase the size, you're increasing
the amount of stack used for each level of recursion in a render.

-- Chris

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> In the case of FixedSimpleVector, that's more difficult than it seems. The
> hard-coded limit is needed because that class is explicitly designed to use
> stack for storage, rather than the heap, which thus means the compiler
> needs to know its size at build time.

  The POSIX standard defines the alloca() function which works like malloc
but allocates space on the stack instead of the heap (and the allocated
space, being on the stack, is automatically freed when the function is
exited). This is often much more efficient than a new/malloc. Of course
there are drawbacks:

  - It's "only" POSIX, not C/C++ standard, so it's not really portable.

  - It allocates space on the stack of the current function being executed,
which means that it has to be called explicitly everywhere where you need it
(which means you can't create eg. a utility class that would use it, because
any member function of that class that would use alloca() would not work,
as the space would be allocated on *that* function's stack space, and hence
freed immediately after the member function returns).

  The newer C standard somewhat circumvents the need for alloca() by
allowing stack-allocated arrays which sizes are determined at runtime
(in other words, doing effectively what alloca() does). However, this
is not part of the C++ standard.

  So the problem is not a trivial one to solve.

-- 
                                                          - Warp

Post a reply to this message

Thanks for the information.

As a workaround I changed the limits from 127 to 1024 and was able to render the
scene successfully.

Is there any limit to the size of the stack?

How much memory does an instance of FixedSimpleVector consume?

I have a scene that has over 2700 lights and I wanted to make sure that changing
the code to handle it would not break anything.

Thank you

Richard

Post a reply to this message

On 4/01/2011 11:30, RM wrote:
> Is there any limit to the size of the stack?

That's platform-specific. Some operating systems/run-time libraries employ
stack guard pages that allow automatic expansion of the stack, others have
fixed sizes per thread.

> How much memory does an instance of FixedSimpleVector consume?

Roughly, the number of elements times the size of the type of element it
contains, per instance, per thread.

For example, the LightSourceEntry structure requires 24 bytes on a 64-bit
platform, so your example of 1024 would give a stack usage of about 24k per
instance for that vector. The LitInterval struct uses 40 bytes per entry.
The Media struct is about 132 bytes.

The reason we don't use a single definition for all the sizes is that there
is no requirement that they all be the same.

> I have a scene that has over 2700 lights and I wanted to make sure that changing
> the code to handle it would not break anything.

I can't guarantee it won't, but if it does I suspect you'll find out fairly
quickly. Please feel free to report back your findings and any info you
discover about memory usage and performance.

-- Chris

Post a reply to this message