Dear developers,

I've recently read about the C++ rewrite of POV. This will be a big work,
but can lead to the best raytracer ever written. Preview rendering is
important when making a big and/or complex scene. Separation of object can
be a solution, but not in all cases. I have years of experience in x86
assembly and SIMD processing, so I can take part in the development of a
"preview renderer" mode for the x86 architecture.

Intel and AMD processors supporting SSE and SSE2 already became popular, so
these instruction sets are widely supported. SSE and SSE2 gives outstanding
performance in single precision floating point arithmetic. I know, it's not
enough for raytracing. But can be definitely enough for color processing and
"preview" quality rendering. Parsing and transforming can be done at full
precision. Then the whole scene can be rounded to single precision as
aligned SSE2 (128 bit) words. There are instructions supporting this.

Multiple rays can be started on the image plane at the same time. For
example, start 5000 rays from a 50x100 rectagle of the image plane.

Each elementary object class (not instance) have it's own processing queue.
Rays are processed in a loop and "intersection requests" are posted to the
object queues for each object respectively (bounding trees requires multiple
passes). After processing a batch of rays all intersection queues are
executed (feeding rays with intersection points and normals). Objects in
each elementary object class can be processed in batch using SSE or SSE2
instructions. SIMD instructions can be utilized with full bandwidth, because
multiple object (such as 4 spheres) can be intersected with different rays
at the same time. For example, 4000 ray-sphere instersections can be
calculated in one batch without a single effective cache miss (due to
prefetch instructions). Queue length and the number of parallel rays can be
optimized according to the measured cache characteristics of the specific
CPU.

Groups of object queues can be adaptively delegated to multiple processors
(in multiprocessor machines) or networked machines (in network rendering
mode). Time consuming intersection operations (such as sturm) can be
delegated to other machines with a running "povray service". Only
intersection calculations can be delegated without copying large amounts of
texture data. Cache usage can be optimized by "prefetch" instructions,
because queue locations are known. The number of effective cache misses
causing wait states can be minimized this way.

Quality rendering with full percision (,anti-aliasing, large number of
reflected rays,...) should be done with double precision, but can be queued
with the same mechanism.

I've some experience in raytracing acceleration using oct-tree auto-bounding
lookups with SIMD (MMX) technology. This can reduce the number of
unnecessary intersection calculations of expensive objects. Infinite objects
and simple ones (spheres, etc.) should not be bounded by this method.

I'll be able to do some research/work in this field after POV-Ray 3.5 source
code is released.

Best regards, Vic

Post a reply to this message

In article <3ccf0305@news.povray.org> , "Vic" <let### [at] fwhu> wrote:

> I've recently read about the C++ rewrite of POV.

No offense, but not another one of these threads, please! :-)

> I have years of experience in x86
> assembly and SIMD processing, so I can take part in the development of a
> "preview renderer" mode for the x86 architecture.
>
> Intel and AMD processors supporting SSE and SSE2
<snip - bunch of speculation and tons of misunderstandings*>

You do realize that POV-Ray is a *cross-platform* program, do you? - And keep
in mind "Premature optimization is the root of all evil." (Donald Knuth)...


    Thorsten


* Hint:  Look into the available source code (profile it!) and suggested
reading section in docs to find out more about what POV-Ray already does and
how ray-tracing works first!

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> * Hint:  Look into the available source code (profile it!) and suggested
> reading section in docs to find out more about what POV-Ray already does and
> how ray-tracing works first!

  I think that one of the biggest problems with people who try to optimize
POV-Ray (or any similar program for that matter) is that they optimize the
wrong things in the wrong ways.
  People usually thing "this should be optimized" without even taking the
trouble of measuring if that thing is consuming most of the rendering time
or not (ie. doing the so-called profiling). If POV-Ray spends 1% of the
rendering time in a certain function, it doesn't help too much to optimize
that function to be 10% faster (which would mean that the total render time
will be about 0.1% faster, so for example a 1-hour render will be reduced
to 59 minutes and 56 seconds).
  Also making a platform-dependant optimization is bad, even if you supply
an alternative using #ifdefs. It's bad because it means code repetition,
which makes changing the code harder.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Try porting POV-Ray to Java instead.... :-)

--
Apache
http://geitenkaas.dns2go.com/experiments/
apa### [at] yahoocom

Post a reply to this message

Apache <apa### [at] yahoocom> wrote:
> Try porting POV-Ray to Java instead.... :-)

  POV-Ray is slow enough already.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message