 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi, all:
I'm a novice in ray tracing. I'm currently parallelizing povray using
threads, but I have problem in making it generate the same result as the
sequential version, I have spent some time in finding the problem, and
found that the random number is the main obstacle. Would you kindly tell me
something on this? What's the random number usage in povray? In my reading
source, I found it is used in supersample/sample distribution. But since
i'm not profession in this area, I have no concrete idea on this. Would you
like to give me some information on this?
Also, I have one question, how do you graphic guys consider whether the
generated result is correct or not? Do you permit certain difference in
pixels?
Thanks.
--
Chen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'm a novice in ray tracing. I'm currently parallelizing povray using
> threads,
If you are a novice to ray-tracing, you should not be doing this at all.
There is a simple reason why POV-Ray is not multithreaded, and that is that
the source code is not up to it without changes to various algorithms that
requires a very good understanding of ray-tracing. I would very strongly
advise to not waste time trying to hack a multithreaded implementation of
the 3.x source code together. It is not going to work completely - ever!
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chen Yang wrote:
> hi, all:
> I'm a novice in ray tracing. I'm currently parallelizing povray using
> threads, but I have problem in making it generate the same result as the
> sequential version, I have spent some time in finding the problem
There's more than one problem :)
> What's the random number usage in povray? I found it is used in supersample/sample
distribution.
It's used all over the place. I solved the threaded-randomness problem
by making the "random" functionality instanced, rather than global.
Using instances rather than globals is the key to making POV-Ray
thread-safe. However, as Thorsten indicated, this is no small
undertaking. Many algorithms in POV-Ray need adjustments to be made
thread-safe.
To your specific question, the anti-aliasing system in POV-Ray is very
anti-threads. I ended up rewriting it.
The technique I'm using is to make two passes on the image. The first
pass is one ray through the middle of the every pixel, storing the raw
result in memory. The second pass compares the in-memory pixels to
their 8 surrounding neighbors and then throws a user-defined amount of
additional rays in an even pattern within the pixel, averaging the results.
The first-to-second-pass transition is the only time the threads have to
synchronize. During the rendering, they each work on their own pixel
and use thread-safe incrementing on a global counter to divide the
workload. It works flawlessly--I've tested it on 4-way Xeon systems
with no artifacts or glitches at all (not to mention that it was very
fast :)
The main drawback to this technique is that it takes 20 bytes of memory
per pixel to hold the buffer for the first pass. 10 years ago, that
problem would have made it unfeasable, but on modern hardware it's not bad.
If one was willing to give up the precision of floating point color
channels, that could be reduced to 4 bytes per pixel by using RGBA
values stored in 8-bit integers.
The result is not quite as good as either of the original algorithms,
but it's not bad at all--most people wouldn't notice. Some further work
could resolve the remaining quality differences, if I had time to spend
on it.
> Also, I have one question, how do you graphic guys consider whether the
> generated result is correct or not? Do you permit certain difference in
> pixels?
Mapping infinitely-precise objects onto square pixels is automatically
"incorrect". In the graphics world, we strive for the best possible
approximation.
-Ryan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks to Thorsten and Ryan, your comments help me a lot!
Another question on ray-tracing, why does parallel ray tracing use screen
space task subdivision? For example, share the scene in all the machines,
and distribute small tiles to different machines. In my knowledge, it seems
that it is to both balance the work and to co-operatte with anti-alias
part, are there any other considerations?
Thanks.
--
Chen
Ryan Lamansky <Spa### [at] kardax com> wrote:
> Chen Yang wrote:
> > hi, all:
> > I'm a novice in ray tracing. I'm currently parallelizing povray using
> > threads, but I have problem in making it generate the same result as the
> > sequential version, I have spent some time in finding the problem
>
> There's more than one problem :)
>
> > What's the random number usage in povray? I found it is used in supersample/sample
distribution.
>
> It's used all over the place. I solved the threaded-randomness problem
> by making the "random" functionality instanced, rather than global.
>
> Using instances rather than globals is the key to making POV-Ray
> thread-safe. However, as Thorsten indicated, this is no small
> undertaking. Many algorithms in POV-Ray need adjustments to be made
> thread-safe.
>
> To your specific question, the anti-aliasing system in POV-Ray is very
> anti-threads. I ended up rewriting it.
>
> The technique I'm using is to make two passes on the image. The first
> pass is one ray through the middle of the every pixel, storing the raw
> result in memory. The second pass compares the in-memory pixels to
> their 8 surrounding neighbors and then throws a user-defined amount of
> additional rays in an even pattern within the pixel, averaging the results.
>
> The first-to-second-pass transition is the only time the threads have to
> synchronize. During the rendering, they each work on their own pixel
> and use thread-safe incrementing on a global counter to divide the
> workload. It works flawlessly--I've tested it on 4-way Xeon systems
> with no artifacts or glitches at all (not to mention that it was very
> fast :)
>
> The main drawback to this technique is that it takes 20 bytes of memory
> per pixel to hold the buffer for the first pass. 10 years ago, that
> problem would have made it unfeasable, but on modern hardware it's not bad.
>
> If one was willing to give up the precision of floating point color
> channels, that could be reduced to 4 bytes per pixel by using RGBA
> values stored in 8-bit integers.
>
> The result is not quite as good as either of the original algorithms,
> but it's not bad at all--most people wouldn't notice. Some further work
> could resolve the remaining quality differences, if I had time to spend
> on it.
>
> > Also, I have one question, how do you graphic guys consider whether the
> > generated result is correct or not? Do you permit certain difference in
> > pixels?
>
> Mapping infinitely-precise objects onto square pixels is automatically
> "incorrect". In the graphics world, we strive for the best possible
> approximation.
>
> -Ryan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Another question on ray-tracing, why does parallel ray tracing use screen
> space task subdivision?
It's the only effective way you could spread the workload.
The existing version of POV-Ray can do this if you use special utilities
or a few command-line or ini file tricks. You can also obtain a degree
of parallel processing on multi-CPU machines by running multiple POV
instances with this technique, although your memory requirements are
multiplied by the number of CPUs.
The challenge is dealing with the fact that with most scenes, different
regions will render at different speeds. For instance, if you had one
machine do the top half and another do the bottom half, with most scenes
the top half (often mostly sky) will be done far sooner than the bottom.
With the SMP route, dividing by pixel is fine because one extra memory
access per pixel is trivial. It's not fine for clustering because
network latency is definitely not trivial.
The solution in my mind is to use relatively small tile sizes (like
32x32 pixels), and add some communication so that different machines are
always working. I like this idea because the machines in a cluster
could be far apart in speed and still be helpful.
Again, this sort of effect can be faked using utility software, but it
couldn't get around the re-parsing, re-radiosity, re-photon shooting
stuff, which can add a considerable amount of time to a complex scene if
it were rendered in small tiles.
Be aware that I'm not on the POV-Team and nothing I'm saying should be
indicative of what POV-Ray 4.0 may or may not be capable of doing. I'm
working on this independantly because it's an interesting challenge.
-Ryan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
