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.

Post a reply to this message

On 2017-02-19 09:00 AM (-4), clipka wrote:
> 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.

Well, Microsoft has washed its hands of WinXP, so I don't see why new 
POV-Ray versions should have to support it.

And if anyone out there is still using XP, you're a sitting duck for any 
security holes that have opened up since 2014.

Post a reply to this message

On 2/19/2017 3:42 PM, Cousin Ricky wrote:
> On 2017-02-19 09:00 AM (-4), clipka wrote:
>> 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.
>
> Well, Microsoft has washed its hands of WinXP, so I don't see why new
> POV-Ray versions should have to support it.
>

That is a fair point. Does PovRay run on a 16 bit OS like Win 3.1?

> And if anyone out there is still using XP, you're a sitting duck for any
> security holes that have opened up since 2014.
>

Only if it is connected to the internet. I can imagine someone keeping 
an old machine as part of a home render farm. Rather than just scrapping it.

-- 

Regards
     Stephen

Post a reply to this message

Am 19.02.2017 um 16:42 schrieb Cousin Ricky:
> On 2017-02-19 09:00 AM (-4), clipka wrote:
>> 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.
> 
> Well, Microsoft has washed its hands of WinXP, so I don't see why new
> POV-Ray versions should have to support it.
> 
> And if anyone out there is still using XP, you're a sitting duck for any
> security holes that have opened up since 2014.

Let's put it this way: As long as anyone posting on these newsgroups on
a regular basis is still using XP, I prefer to keep POV-Ray alive on
that operating system.

I'd think differently about any other application; but POV-Ray is one of
the few pieces of software that make sense to be installed on an old
shoe box in a corner, with a presumably equally old operating system.

Post a reply to this message

Am 19.02.2017 um 17:13 schrieb Stephen:
> On 2/19/2017 3:42 PM, Cousin Ricky wrote:
...
>> Well, Microsoft has washed its hands of WinXP, so I don't see why new
>> POV-Ray versions should have to support it.
> 
> That is a fair point. Does PovRay run on a 16 bit OS like Win 3.1?

Apples and oranges.

Continuing support for 16-bit Windows 3.1 would have meant maintaining a
separate obsolete strain of POV-Ray (namely POV-Ray for DOS).

Continuing support for Windows XP is just a matter of retaining
compatibility with it in an actively maintained strain of POV-Ray
(namely POV-Ray for Win32).

If you want to draw any comparison, it might be more fitting to ask
about support for Windows 95 (or even Windows 3.1 with Win32s).


BTW, POV-Ray seems to have seen the following official major strains:

- POV-Ray for Amiga
- POV-Ray for DOS (and Windows 3.1 and OS/2)
- POV-Ray for Mac ("classic" Mac OS)
- POV-Ray for Unix (including Mac OS X)
- POV-Ray for Win32 (including its 64-bit variant)

Of these, the first three have been discontinued.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

>
> Well, Microsoft has washed its hands of WinXP, so I don't see why new
> POV-Ray versions should have to support it.
>

I would still be using my 32-bit WinXP machine, if the motherboard hadn't died
six months ago (which I rather reluctantly had to replace with a used Win7
64-bit machine-- not Win10, which I didn't want.)

My reason for wanting to stick with XP? Stability. And familiarity. It's not
that I'm against upgrading to newer OS versions; it's just that the learning
curve 'gets in the way', so to speak. I would rather be *productive* on a
computer, instead of having to spend lots of time getting used to a new OS and
its quirks. Even Win7 is somewhat of a new learning curve, for me. I do miss my
XP machine.

That said, I do appreciate the ability to finally use a 64-bit version of
POV-Ray, as well as other apps that require such an OS (AND to finally have a
computer with more than one core!)

My own opinion is that there is still plenty of life left in older machines and
OS's. (I actually still have a Win98 machine(!)-- offline-- because, right now,
it's my only machine with Photoshop installed; an older version, but still quite
useful.)

Post a reply to this message

On 2017-02-20 01:13 AM (-4), Kenneth wrote:
> My reason for wanting to stick with XP? Stability. And familiarity. It's not
> that I'm against upgrading to newer OS versions; it's just that the learning
> curve 'gets in the way', so to speak. I would rather be *productive* on a
> computer, instead of having to spend lots of time getting used to a new OS and
> its quirks. Even Win7 is somewhat of a new learning curve, for me. I do miss my
> XP machine.

I feel your pain.  The Win7 learning curve was so steep, I ended up 
switching to GNU/Linux!

I use Win10 away from home, and find it far less unpleasant than Win7, 
though I still would have preferred the straightforwardness of WinXP. 
Unfortunately(?), I boot up Win7 at home so seldom that it hasn't had a 
chance to download Win10.

Post a reply to this message

On 19/02/2017 8:00 AM, clipka wrote:
...
> we have therefore decided to keep the 32-bit binaries
> XP-compatible for now,
...

Warning popup:

This build of POV-Ray requires that your processor provides SSE2 
support. Please use the standard non-SSE2 version of POV-Ray on this 
computer.

AMD Athlon 64 X2 4200+ 2.19 GHz, 2.00 GB of RAM

I used to be able to run both on this computer.

pvengine.exe runs, linked to older downlaoded editor?, not opening 
files. I still have the alternate editor file, will run with that.

....
I only have a newer alternate cmedit32-sse2.dll

Stephen S

Post a reply to this message

On 19/02/2017 1:35 PM, clipka wrote:
...
> Let's put it this way: As long as anyone posting on these newsgroups on
> a regular basis is still using XP, I prefer to keep POV-Ray alive on
> that operating system.
>
...
I post about Win XP32, I render on Win10 64bit.

Although there maybe others out there ;-)

Stephen S

Post a reply to this message

On 20/02/2017 11:28 AM, StephenS wrote:

> ....
> I only have a newer alternate cmedit32-sse2.dll
>
I'm not sure what I have, needs more testing.

Stephen S

Post a reply to this message

Am 20.02.2017 um 17:44 schrieb StephenS:
> On 20/02/2017 11:28 AM, StephenS wrote:
> 
>> ....
>> I only have a newer alternate cmedit32-sse2.dll
>>
> I'm not sure what I have, needs more testing.
> 
> Stephen S

As a workaround, you might simply rename or copy that DLL to
`cmedit32.dll`, and do the corresponding for `povcmax32-sse2.dll`.

Post a reply to this message

Am 20.02.2017 um 17:39 schrieb StephenS:
> On 19/02/2017 1:35 PM, clipka wrote:
> ....
>> Let's put it this way: As long as anyone posting on these newsgroups on
>> a regular basis is still using XP, I prefer to keep POV-Ray alive on
>> that operating system.
>>
> ....
> I post about Win XP32, I render on Win10 64bit.

So you're saying you're no longer using POV-Ray on XP yourself?

Well, that might change things...

Post a reply to this message

Am 20.02.2017 um 17:28 schrieb StephenS:

> Warning popup:
> 
> This build of POV-Ray requires that your processor provides SSE2
> support. Please use the standard non-SSE2 version of POV-Ray on this
> computer.

I have some hunch where this might be coming from.

I might be bombarding you with a few test executables in the next few
days to get to the bottom of it.

Post a reply to this message

On 20/02/2017 12:27 PM, clipka wrote:
...
>> I post about Win XP32, I render on Win10 64bit.
>
> So you're saying you're no longer using POV-Ray on XP yourself?
>
> Well, that might change things...
>

I will continue to turn on my 'old' Win XP computer and play games, and 
even use POV-Ray on it, but I only need pov v3.6 for this.

I no longer use XP for rendering of scene files for output. It has been 
used for CSG visualization with a OpenGL GUI modeller for years now. 
Anything not supported has been hand coded with #if (version xxxxxx) 
something.

I would fully support POV-Ray 3.70 as the last fully supported Win XP.

I can only speak for myself, but I no long need POV-Ray for Win XP.

Stephen S

Post a reply to this message

On 20/02/2017 11:28 AM, StephenS wrote:
...
> pvengine.exe runs, linked to older downlaoded editor?, not opening
> files. I still have the alternate editor file, will run with that.
...
Used the suggestion from Chris, copied over 3.7.0 editor files.
Up and running now.

Stephen S

Post a reply to this message

On 20/02/2017 1:00 PM, clipka wrote:
> Am 20.02.2017 um 17:28 schrieb StephenS:
>
>> Warning popup:
>>
>> This build of POV-Ray requires that your processor provides SSE2
>> support. Please use the standard non-SSE2 version of POV-Ray on this
>> computer.
>
> I have some hunch where this might be coming from.
>
> I might be bombarding you with a few test executables in the next few
> days to get to the bottom of it.
>
I'm willing to test if your willing to put in the time to make the 
executable.

Stephen S

Post a reply to this message

On 2/19/2017 7:16 PM, clipka wrote:
> Am 19.02.2017 um 17:13 schrieb Stephen:
>> On 2/19/2017 3:42 PM, Cousin Ricky wrote:
> ....
>>> Well, Microsoft has washed its hands of WinXP, so I don't see why new
>>> POV-Ray versions should have to support it.
>>
>> That is a fair point. Does PovRay run on a 16 bit OS like Win 3.1?
>
> Apples and oranges.
>

That is a metaphor I have never been able to understand even as a child.
Of course you can compare apples and oranges. They are both fruit and 
grow on trees. You can even add them.

I really commend the Pov team for their work on compatibility. It is 
unusual in the software world.


-- 

Regards
     Stephen

Post a reply to this message

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.

I don't know whether you are interested to use such source for debugging and how
I can contribute such source?

BR Billabong

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.

Post a reply to this message

On 02/25/2017 07:20 AM, Billabong wrote:
> 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.
>
> I don't know whether you are interested to use such source for debugging and how
> I can contribute such source?
>
> BR Billabong
>
>

Yes, interested. If you can prune down to some minimal set of SDL 
causing the crash(1) - more interested :-). Pruned to a small number of 
lines you can post it inline here. Otherwise largish text files can be 
posted to the povray.text.scene-files group (or as an attachment to a 
new github issue - needs to have a .txt suffix added). If you can create 
zip files or tar files these can be posted as binaries to the 
povray.binaries.scene-files group or again to github as an attachment to 
an issue.

There is further detail on how to report bugs at the bottom of this wiki 
page:

http://wiki.povray.org/content/HowTo:Contents

Bill P.

Post a reply to this message

Hi again,
the source is not too long, so I simply pasted it below.
BR Billabong

//================

#version 3.7;

global_settings {
  assumed_gamma 2.2
  max_trace_level 16
}


camera {
  location  <0,1,-2.8>
  up <0,1,0>
  right <1,0,0>
  look_at <0,1,10>
}

#declare Y = -0.2;
#while (Y<2.2)
    light_source {
        0*x
        color rgb 0.7
        translate <0, Y,0.7>
    }
    #declare Y = Y + 0.2;
#end

light_source {
    0*x
    color rgb 2
    translate <0, 0.7,1.7>
}
//--------

sky_sphere { pigment { rgb 1} }

#declare Random = seed(7);

#macro Ice_Texture(Random)
 texture  {
  pigment {
     color rgbf <0.5+rand(Random)/5,0.8+rand(Random)/5,1-rand(Random)/10,1>
  }
  finish {
   diffuse 0.9
   reflection 0.05
   brilliance 7
  }
 }
#end


#macro Fire_Texture(Random,Transparenz)
 texture {
  pigment {
     color rgbf
<1-rand(Random)/10,0.15+rand(Random)/10,rand(Random)/10,Transparenz>
  }
  normal { quilted scale 1-rand(Random)/4 }
  finish {
   diffuse 0.9
   ambient 0.5
   reflection 0.2
   brilliance 2
  }
 }
#end

#macro Triangle_SplitF(point1,point2,point3,Nesting,Transparenz)
  #if(Nesting<15)
   #if(vlength(point1-point2)>vlength(point2-point3))
    #if(vlength(point1-point2)>vlength(point1-point3))
     #local point4 = point1 + (0.4+rand(Random)*0.2)*(point2-point1);
     Triangle_SplitF(point1,point3,point4,Nesting+1,Transparenz)
     Triangle_SplitF(point2,point3,point4,Nesting+1,Transparenz)
    #else
     #local point4 = point1 + (0.4+rand(Random)*0.2)*(point3-point1);
     Triangle_SplitF(point1,point2,point4,Nesting+1,Transparenz)
     Triangle_SplitF(point2,point3,point4,Nesting+1,Transparenz)
    #end
   #else
    #if(vlength(point2-point3)>vlength(point1-point3))
     #local point4 = point2 + (0.4+rand(Random)*0.2)*(point3-point2);
     Triangle_SplitF(point1,point3,point4,Nesting+1,Transparenz)
     Triangle_SplitF(point2,point1,point4,Nesting+1,Transparenz)
    #else
     #local point4 = point1 + (0.4+rand(Random)*0.2)*(point3-point1);
     Triangle_SplitF(point1,point2,point4,Nesting+1,Transparenz)
     Triangle_SplitF(point2,point3,point4,Nesting+1,Transparenz)
    #end
   #end
 #else
  triangle{point1,point2,point3 Fire_Texture(Random,Transparenz)}
 #end
#end

Triangle_SplitF(<-10,-10,5>,<10,-10,5>,<10,10,5>,0,0)
Triangle_SplitF(<-10,-10,5>,<-10,10,5>,<10,10,5>,0,0)


#macro Tetraeder(point1,point2,point3,point4,Texture)
mesh {
 triangle{point1,point2,point3 texture{Texture}}
 triangle{point1,point2,point4 texture{Texture}}
 triangle{point1,point4,point3 texture{Texture}}
 triangle{point4,point2,point3 texture{Texture}}
}
#end


#macro Tetraeder_Split(point1,point2,point3,point4,Nesting)
  #if(Nesting<12)
   #local vl12 = vlength(point1-point2);
   #local vl13 = vlength(point1-point3);
   #local vl14 = vlength(point1-point4);
   #local vl23 = vlength(point2-point3);
   #local vl24 = vlength(point2-point4);
   #local vl34 = vlength(point3-point4);
   #if(vl12>=vl13 & vl12>=vl14 & vl12>=vl23 & vl12 >= vl24 & vl12 >= vl34)
    #local point1a = point1;
    #local point2a = point2;
    #local point3a = point3;
    #local point4a = point4;
   #else
    #if(vl13>=vl14 & vl13>=vl23 & vl13 >= vl24 & vl13 >= vl34)
     #local point1a = point1;
     #local point2a = point3;
     #local point3a = point2;
     #local point4a = point4;
    #else
     #if(vl14>=vl23 & vl14 >= vl24 & vl14 >= vl34)
      #local point1a = point1;
      #local point2a = point4;
      #local point3a = point2;
      #local point4a = point3;
     #else
      #if(vl23 >= vl24 & vl23 >= vl34)
       #local point1a = point2;
       #local point2a = point3;
       #local point3a = point1;
       #local point4a = point4;
      #else
       #if(vl24 >= vl34)
        #local point1a = point2;
        #local point2a = point4;
        #local point3a = point1;
        #local point4a = point3;
       #else
        #local point1a = point3;
        #local point2a = point4;
        #local point3a = point1;
        #local point4a = point2;
       #end
      #end
     #end
    #end
   #end

   #local point5a = point1a + (0.4+0.2*rand(Random))*(point2a-point1a);
   Tetraeder_Split(point1a,point4a,point3a,point5a,Nesting+1)
   Tetraeder_Split(point2a,point4a,point3a,point5a,Nesting+1)
 #else
  Tetraeder(point1,point2,point3,point4,Ice_Texture(rand(Random)))
 #end

#end

Tetraeder_Split(<-0.8,0,-0.8>,<0.8,0,-0.8>,<0,2.4,0>,<0,0,-0.7>,0)
Tetraeder_Split(<-0.8,0,0.8>,<0.8,0,0.8>,<0,2.4,0>,<0,0,0.7>,0)
Tetraeder_Split(<-0.8,0,-0.8>,<-0.8,0,0.8>,<0,2.4,0>,<-0.7,0,0>,0)
Tetraeder_Split(<0.8,0,-0.8>,<0.8,0,0.8>,<0,2.4,0>,<0.7,0,0>,0)

triangle {<-1.45,-0.8,0.8>,<1.45,-0.8,0.8>,<0,2.8,0.8> pigment {rgb 1} }













William F Pokorny <ano### [at] anonymousorg> wrote:
> On 02/25/2017 07:20 AM, Billabong wrote:
> > 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.
> >
> > I don't know whether you are interested to use such source for debugging and how
> > I can contribute such source?
> >
> > BR Billabong
> >
> >
>
> Yes, interested. If you can prune down to some minimal set of SDL
> causing the crash(1) - more interested :-). Pruned to a small number of
> lines you can post it inline here. Otherwise largish text files can be
> posted to the povray.text.scene-files group (or as an attachment to a
> new github issue - needs to have a .txt suffix added). If you can create
> zip files or tar files these can be posted as binaries to the
> povray.binaries.scene-files group or again to github as an attachment to
> an issue.
>
> There is further detail on how to report bugs at the bottom of this wiki
> page:
>
> http://wiki.povray.org/content/HowTo:Contents
>
> Bill P.

Post a reply to this message

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