Am 25.02.2017 um 13:20 schrieb Billabong:
> Thank you so much for pushing forward for a new release stepping of Povray.
> 
> I am new in this forum. I have been using V3.7 for some years and now trying out
> the beta releases. I am re-rendering some of the old competition sources and
> found a source file that crashes at parsing in beta.3 and also beta.2, but runs
> fine on the v3.7. I have a pretty standard machine running Win10.

Can you be more specific about the scene "crashing"?

I do notice a pause between parsing and the start of the render,
probably related to the many warning messages your scene produces, but
after a few seconds the render does proceed.

You can avoid the warning messages (and the unexpected pause) by
replacing "ambient 0.5" with "emission 0.5" in the "Fire_Texture" macro,
or by using "#version 3.6" instead of "#version 3.7".

Post a reply to this message

On 02/27/2017 06:16 AM, clipka wrote:
> Am 25.02.2017 um 13:20 schrieb Billabong:
>
> Can you be more specific about the scene "crashing"?
>
>

I'm able to run the posted SDL on my Ubuntu 16.04 linux machine as well.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> I'm able to run the posted SDL on my Ubuntu 16.04 linux machine as well.
> Bill P.

I'm running on my work laptop (Win 8, i5) and at 800 x 600 a0.3, it took about 3
hours to render - but no crash.


Very nice, but I think there's gotta be a faster way to get 99% of the look.  :O

Please keep working on this scene and share some of your experiments and
improvements!

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Can you be more specific about the scene "crashing"?
>
> I do notice a pause between parsing and the start of the render,
> probably related to the many warning messages your scene produces, but
> after a few seconds the render does proceed.
>
> You can avoid the warning messages (and the unexpected pause) by
> replacing "ambient 0.5" with "emission 0.5" in the "Fire_Texture" macro,
> or by using "#version 3.6" instead of "#version 3.7".

You are right, I was too impatient, there is no crashing.
First I replaced "ambient" by "emission", so getting rid of all messages.
Then the SDL parses correctly and rendering starts after some seconds.
The generated object are counted-up in the status line, so everything is fine.

You are also right, the pausing is caused by the warning messages.
To provoke this effect even more, I left the "ambient" and added a few lines of
"#render" within the recursion loop containing a long string with bad
characters. This caused -really- many warnings!

The effect on the GUI is very similar to a crash.
After pressing "Run" warning messages start to list up in the bottom status
line. After 2-3 seconds, the status line freezes. If I then try to switch to the
"Messages" Tab, the entire GUI freezes, the cursor starts to spin and the window
is saying "not responding".
However, if I check the status of the CPU cores, I see that all are fully in
use, which is a sign that rendering has started already. During parsing just a
single core is used. So obviously parsing has finished, rendering has started,
but the GUI is still hanging and busy with warning message output.

After provoking such many warning messages, this state of freeze lasted about 30
seconds, after that the GUI recovers and jumps immediately to showing the render
progress, and there is it also obvious that rendering has taken place during the
freeze state.

I tried the trick with using the unsupported #render / #statistic console output
pipe also with v3.7 and the effect was the same, so this issue seems to be not
new in this beta.

I have a pretty fast CPU, and if just one of the cores is used (which is the
case for parsing) the core goes into turbo mode at higher clock-rates. So my
guess would be that the parser generates the warning triggers faster than the
GUI console can output them, in particular if the warning string is long, which
is the case for the "ambient" warning. An additional problem is that rendering
is started using all cores, so the core used for the GUI and the message output
is pushed into its limit by the additional load from the rendering thread,
causing the freeze state to be even longer.

So no crash, but the effect looks very similar and an impatient user will not
wait but kill the window immediately. In times of fast CPUs, maybe the thread
distribution has to be reconsidered?

BR Billabong

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Since the beans have been spilled already, it's no use denying it
> anymore -- v3.7.1-beta.3 is available on GitHub:
>
> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-beta.3
>
> Besides fixing a few bugs, this version should also improve performance
> on 64-bit Windows machines over the previous beta -- especially if your
> scene makes plenty use of noise and your CPU supports AVX2 and FMA3
> (thanks to hand-optimized code courtesy of Intel); other scenes and CPUs
> should also profit though.
>
> Unfortunately this performance gain comes at the cost of dropping
> support for Windows XP (and Windows Server 2003). In order to still be
> able to provide some level of support for these legacy operating
> systems, we have therefore decided to keep the 32-bit binaries
> XP-compatible for now, which on the other hand means that users of later
> 32-bit Windows versions will miss out on the performance improvements.
>
> Note that the choice between XP-compatibility and performance is a
> matter of the build tool used (Visual Studio 2010 will generate
> XP-compatible binaries, while Visual Studio 2015 will generate faster
> ones), so 64-bit XP-compatible binaries /can/ still be built from the
> source code, as can faster 32-bit binaries.

Bad news for me, I've WinXP64 on all my machines.

Post a reply to this message

Am 02.03.2017 um 23:33 schrieb LucasGrijander:
> clipka <ano### [at] anonymousorg> wrote:
>> Since the beans have been spilled already, it's no use denying it
>> anymore -- v3.7.1-beta.3 is available on GitHub:
>>
>> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-beta.3
>>
>> Besides fixing a few bugs, this version should also improve performance
>> on 64-bit Windows machines over the previous beta -- especially if your
>> scene makes plenty use of noise and your CPU supports AVX2 and FMA3
>> (thanks to hand-optimized code courtesy of Intel); other scenes and CPUs
>> should also profit though.
>>
>> Unfortunately this performance gain comes at the cost of dropping
>> support for Windows XP (and Windows Server 2003). In order to still be
>> able to provide some level of support for these legacy operating
>> systems, we have therefore decided to keep the 32-bit binaries
>> XP-compatible for now, which on the other hand means that users of later
>> 32-bit Windows versions will miss out on the performance improvements.
>>
>> Note that the choice between XP-compatibility and performance is a
>> matter of the build tool used (Visual Studio 2010 will generate
>> XP-compatible binaries, while Visual Studio 2015 will generate faster
>> ones), so 64-bit XP-compatible binaries /can/ still be built from the
>> source code, as can faster 32-bit binaries.
> 
> Bad news for me, I've WinXP64 on all my machines.

Thanks for letting us know; this is important feedback for us.
For a more complete picture, may I ask what CPUs you are running XP x64 on?

That said, remember you should still be able to run official POV-Ray on
your Windows XP x64 machines by using the 32-bit SSE2 binary.

While the current installer doesn't properly handle XP x64, still
registering the (now incompatible) 64-bit binaries instead of the 32-bit
SSE2 binaries (or at least that's what we expect; we haven't had a
chance to actually test it), we are fully aware of this problem, and are
committed to fixing it in the next beta.

Post a reply to this message