 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I finally got around to downloading a beta (3.7b24, Windows version).
First time I tried it, so just my stupid-average-user observations here.
Not complaining about anything, it's working fine and looks stable ;)
o It would be nice if the download ZIP contained a short README
listing some "major new features" as compared to 3.6.x (it is easy
to overlook them in the multitude of praiseworthy bug fixes), and
a quick note about how to best use the files in the beta ZIP to
get a runnable 3.7b without destroying the existing 3.6.x (what
I did was to create a copy of bin as "bin37b" and dump the
contents of the ZIP file in there).
o On my P4/2.6Ghz with XP, rendering some random scenes seemed to
take at least 2 times longer than with 3.6.1. After setting the
thread count from default value of 2 to 1, this improved but still
took at least 1.4 times longer than with 3.6.1 (even with sse2).
Actually I wonder if the default thread count shouldn't be 1,
to make the default behavior mostly like 3.6.x. Many people will
not yet have a dual-core at home, and even those who do might be
used to having the system operational while rendering in the
background. Or maybe default thread count = 0, interpreted
as automatic: thread count = number of cpus reported by OS?
Furthermore, I think the thread count in the Windows GUI
should persist.
o I noticed 3.7 now has support for HDR's but not the map_type 7
which is implemented in Mega-POV to support the omnidirectional
images which seem to be a typical use case for HDR's. Moreover,
there is no syntax error when using an unsupported map_type,
the image_map seems to silently revert to map_type 0.
o I know about the #version directive, but is there some built-in
define to test the engine version using #ifdef, e.g., how could
you create a HDR scene which renders both in MegaPOV and 3.7?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin wrote:
> I finally got around to downloading a beta (3.7b24, Windows version).
> First time I tried it, so just my stupid-average-user observations here.
> Not complaining about anything, it's working fine and looks stable ;)
This should probably go in the beta group (that's what its for, after
all). That being said,
> o It would be nice if the download ZIP contained a short README
> listing some "major new features" as compared to 3.6.x (it is easy
> to overlook them in the multitude of praiseworthy bug fixes), and
> a quick note about how to best use the files in the beta ZIP to
> get a runnable 3.7b without destroying the existing 3.6.x (what
> I did was to create a copy of bin as "bin37b" and dump the
> contents of the ZIP file in there).
The major new feature of 3.7b is multithreading. There are a few others
(improved bounding, full area light calculations for specular and
diffuse), but most people won't notice those right away.
> o On my P4/2.6Ghz with XP, rendering some random scenes seemed to
> take at least 2 times longer than with 3.6.1. After setting the
> thread count from default value of 2 to 1, this improved but still
> took at least 1.4 times longer than with 3.6.1 (even with sse2).
There is some overhead on single threaded processors; there always will
be when writing multithreaded code. Even so, most computers have a
lifespan of 3-5 years, so within 2 more years almost everyone will be
using multithreaded computers (from two to eight cores, and AMD is even
planning a 3 core version :) ).
> background. Or maybe default thread count = 0, interpreted
> as automatic: thread count = number of cpus reported by OS?
There is no platform independed way to determine the number of CPUs. As
I understand it, under Windows the default is the number of CPUs
reported by the OS (If you havea Pentium 4, it's probably reporting two
CPUs because of Hyperthreading), while under Linux the default is 2.
> o I noticed 3.7 now has support for HDR's but not the map_type 7
> which is implemented in Mega-POV to support the omnidirectional
> images which seem to be a typical use case for HDR's. Moreover,
> there is no syntax error when using an unsupported map_type,
> the image_map seems to silently revert to map_type 0.
Hmm, sounds like a bug.
> o I know about the #version directive, but is there some built-in
> define to test the engine version using #ifdef, e.g., how could
> you create a HDR scene which renders both in MegaPOV and 3.7?
Not that I know of; however, if you try to specify a scene to work with
Megapov, it won't render in 3.7 without the parser complaining, and like
wise for the reverse.
--
...Ben Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin <chr### [at] chrfr de> wrote:
> o On my P4/2.6Ghz with XP, rendering some random scenes seemed to
> take at least 2 times longer than with 3.6.1.
In my 3.2GHz P4 linux box pov3.7beta is faster than pov3.6.1. For example
one test scene with basic CSG at 640x480 +a0.1 +am2 takes 1min 29 seconds
with pov3.6.1 and 48 seconds with pov3.7beta, using 2 threads. The difference
in speed in favor of 3.7beta is remarkable.
I think there was some compiler issue with the Windows version, explaining
the opposite effect there.
> After setting the
> thread count from default value of 2
The thread count has no default in the Windows version. It's calculated
from the number of cores. (Hyperthreading causes programs to see two
cores.)
> to 1, this improved but still
> took at least 1.4 times longer than with 3.6.1 (even with sse2).
I see the opposite effect here. Rendering with one thread makes the
rendering slightly slower than with two threads. (The exact amount depends
a lot on the scene.)
There's really no reason why rendering with more threads than cores
would be slower than rendering with one single thread. The OS makes
approximately the same amount of work in either case and there's practically
no overhead. There might be some issues with caches, but I haven't noticed
it at least here.
On the contrary, rendering with multiple threads may even lead to
slightly faster renderings even with one single core because of time
not being wasted in I/O. (Of course in the case of POV-Ray the difference
is minuscule because it performs so little I/O compared to the amount of
CPU work.)
It might be a compiler issue.
> Actually I wonder if the default thread count shouldn't be 1,
There's no default thread count in the Windows version. It makes as
many threads as cores (and hyperthreading makes it look like there
are two).
> to make the default behavior mostly like 3.6.x. Many people will
> not yet have a dual-core at home, and even those who do might be
> used to having the system operational while rendering in the
> background.
On the contrary. Those who do have multicore CPUs expect POV-Ray to
use full capacity and would get puzzled if it doesn't (especially since
pov3.7 is advertised to be able to). Heck, some people are puzzled by
this with pov3.6 which does not support multithreading (ever seen those
posts like "povray is only using 50% of the CPU, how can I make it use
100%?")
> o I know about the #version directive, but is there some built-in
> define to test the engine version
There's a builtin variable named 'version'.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers wrote:
> This should probably go in the beta group
Oops ... sorry, didn't notice that one, redirecting follow-ups.
>> o It would be nice if the download ZIP contained a short README
>> listing some "major new features" as compared to 3.6.x (it is easy
>> to overlook them in the multitude of praiseworthy bug fixes)
>
> The major new feature of 3.7b is multithreading. There are a few
> others (improved bounding, full area light calculations for specular
> and diffuse), but most people won't notice those right away.
yes, that's why I suggested the list, to see what's of interest
in the new version for people which don't need the threading ;)
>> o On my P4/2.6Ghz with XP, rendering some random scenes seemed to
>> take at least 2 times longer than with 3.6.1. After setting the
>> thread count from default value of 2 to 1, this improved but still
>> took at least 1.4 times longer than with 3.6.1 (even with sse2).
>> Furthermore, I think the thread count in the Windows GUI
>> should persist.
>
> There is some overhead on single threaded processors; there always
> will be when writing multithreaded code.
Well, not *that* much overhead. Warp mentioned compiler problems
on the Windows version, is this a known open issue? Has anyone else
checked rendering speed with 3.7b24 on a P4 running Windows XP?
I know everything will be dualcore in a few years but today
it shouldn't yet be such an uncommon system ;)
>> o I noticed 3.7 now has support for HDR's but not the map_type 7
>> which is implemented in Mega-POV to support the omnidirectional
>> images which seem to be a typical use case for HDR's. Moreover,
>> there is no syntax error when using an unsupported map_type,
>> the image_map seems to silently revert to map_type 0.
>
> Hmm, sounds like a bug.
ok, I now checked this with 3.6.1 and it also accepts any value
for map_type so this parser problem is not specific to the beta.
Just a minor pitfall when adapting MegaPOV HDR scenes to 3.7.
Otherwise, of course, no one enters undocumented values ;)
>> can you create a HDR scene which renders both in MegaPOV and 3.7?
>
> Not that I know of; however, if you try to specify a scene to work
> with Megapov, it won't render in 3.7 without the parser complaining,
> and like wise for the reverse.
I succeeded using the built-in version variable:
#if (version < 3.7)
#version unofficial megapov 1.2;
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
