nope ...

DX9 is completely programmable ...
you could theoretically send some "mini-programs" to the DX9-chip
and run them there...

the only question is, if this is really faster, because the
comunication overhead could make this worse.
OTOH ATis Radeon9700 has several parallel (IIRC 6-8) such pipelines,
so if all the data needed fits in the memory of the card and the "processors"
support all the needed operations it could be a nice idea ...

But to be honest: I don't believe that this is worth for POV, because the code will
become a mess

Post a reply to this message

It is a very interesting point of view.

From a practical point of view, the Dual REAL physical processor will be
faster than an HyperThreading single physical Processor system in many case,
I agree. And I will be very happy if you buy two processors, instead of one
;-)

On the other side, we saw a lot of funky thinks when you have multithreaded
applications, like video decoding, or 3D pipelines using multiple threads,
because some time, the CPU2 ask a write combine from the CPU1 and that is
colliding with the regular memory traffic. (the L2 caches from CPU1 and CPU2
dispute the ownership of the data) In the case of Hyperthreading, we do not
see this. The return on investment, from a processing power point of view is
much better with Hyperthreading.

Hyperthreading was design to increase the decoding capability of your
processors, right now, the decoder is the bottle neck in your processor.
Your execution units are not fully used, due to the fact that your rendering
place a lot of memory request and wait for the answers (300 to 400 Cycles)
in a regular CPU, you will be waiting for the cache line to arrive via the
front side bus and do NOTHING, with hyperthreading, the second logical CPU
will have 300 cycles to do what ever it wants, from reading from L1 or L2
cache, to crunching data with int or float. It is a huge room for
improvement, specially for programs like PovRay that use a lot of memory.

By the way, I speak a little german, so I tried to understand how you did
implement the multithreading, and I was not able the figure out, can you
explain?
Can you share the source code?

Remember, Hyperthreading just improve the return on investment of each
transistor in the Processor, and that is a big deal if you are looking for
Processing power.

Francois




"Theo Gottwald *" <The### [at] t-onlinede> wrote in message
news:3d5677bd@news.povray.org...
> Sounds really good.
>
> However the speed increase in Hyperthreading is diffrent to true
> "smp-multiprocessing-systems".
>
> while in multiprocessing systems you have a REAL SECOND FPU, you have
> in a "Hyperthreading system" no physical second CPU" but just two
> register-sets and caches.
>
> So the speed win comes if one process is halted or used, I doubt we can
have
> real
> 45% increase like with a true SMP-System. After what I have read till now,
> Floating-point calculations may be one of the things that get least speed
> improvements from "jackson technology hyperthreading". 25% ?
>
>
> However the Intel approach to help enable multiprocessing in standard
> applications is a good idea and
> I welcome it at any time cause its the way to the PC's of the future..
>
> Also Intel has always had very good SMP-System.
>
> BTW ...
> Some more thinkings ...
> - what do we think about a commandline-switch "-use_SSE" (Intel Streaming
> Extensions) ?
>  :-) is it usable and could it speed up this sort of calculations ?
>
> NVIDIA has just running a study to make Raytracing in Hardware.
> - could we use direct X 9 under windows to get speed improvements in
future
> versions ?
>
> --Theo Gottwald
>
> PS: So long you all work on "the real thing" I've been doing a "so long
> solution".
>      I've put a BETA-Test Version up which supports as many processors as
> anyone may have.
>      In one or in ten PC's.
>      It currently does not support animations and its in Gemran. But maybe
> in a few days ...
>      The link is http://www.it-berater.org/smpov.htm
>
>
>
>
>
>
> "Chris Cason" <new### [at] deletethispovrayorg> schrieb im Newsbeitrag
> news:3d562831@news.povray.org...
> >
> > "Francois Piednoel" <fra### [at] intelcom> wrote in message
> news:3d55aa5d$1@news.povray.org...
> > > we are already working closely with Chris Cason, and we hope to
improve
> > > again the Pentium(R) 4 user experience, via some more improvement.
> >
> > And I would like to take this opportunity to publicly thank Francois for
> his
> > hard work on the P4 optimizations already in 3.5. I am quite looking
> forward
> > to seeing his hyperthreading implementation.
> >
> > -- Chris
> >
> >
>
>

Post a reply to this message

In article <3d5825ba@news.povray.org> , "Francois Piednoel" 
<fra### [at] intelcom> wrote:

> On the other side, we saw a lot of funky thinks when you have multithreaded
> applications, like video decoding, or 3D pipelines using multiple threads,
> because some time, the CPU2 ask a write combine from the CPU1 and that is
> colliding with the regular memory traffic.

A bit off-topic:  Recently someone suggested to me that something like this
would be efficient* on x86 processors in a multiprocessor environment. This
is assuming two (or more threads) access the same data structure and one
thread is writing to it:

volatile int flag;        // toggle between matrix 1 and 2 to
struct {                  // allow one thread to modify matrix1
    double matrix1[4][4]; // and one or more others to read
    double matrix2[4][4]; // the other matrix2 or vice versa
}

Is there any information for programmers by Intel available (to the public)
regarding code like the above compared to more abstract ways of doing
parallel access?  Or, more general about parallel read/write access pitfalls
and performance suggestions on x86 systems?

    Thorsten

* At least more efficient than a simple lock and using a single data
structure assuming there are many (at least tens of thousands or more per
second) locks/unlocks.

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Sun, 11 Aug 2002 18:56:33 +1000, "Chris Cason"
<new### [at] deletethispovrayorg> wrote:
> And I would like to take this opportunity to publicly thank Francois for his
> hard work on the P4 optimizations already in 3.5. I am quite looking forward
> to seeing his hyperthreading implementation.

Since there are some press informations about HyperThreading are there also
some news about optimizations made for POV ?

ABX

Post a reply to this message

"ABX" <abx### [at] abxartpl> wrote in message
news:c051ou8urot243j2homt8ajerhjjif0c52@4ax.com...
> Since there are some press informations about HyperThreading are there also
> some news about optimizations made for POV ?

No, I know nothing specific.

- Chris

Post a reply to this message

On Fri, 13 Sep 2002 22:10:49 +1000, "Chris Cason"
<new### [at] deletethispovrayorg> wrote:
> > Since there are some press informations about HyperThreading are there also
> > some news about optimizations made for POV ?
>
> No, I know nothing specific.

I have wrote to Francois Piednoel when he asked that one place where threading
could be applied is spline interpolation. Every dimension can be calculated
parallel becouse not influence each other. That's only idea. I can't imagine
how it could be written in the sources to point compiler it should be compiled
with threading.

ABX

Post a reply to this message

In article <90m3ou8uubbqfdu6m3ailgpg7n4gtss85u@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> On Fri, 13 Sep 2002 22:10:49 +1000, "Chris Cason"
> <new### [at] deletethispovrayorg> wrote:
>> > Since there are some press informations about HyperThreading are there also
>> > some news about optimizations made for POV ?
>>
>> No, I know nothing specific.
>
> I have wrote to Francois Piednoel when he asked that one place where threading
> could be applied is spline interpolation. Every dimension can be calculated
> parallel becouse not influence each other. That's only idea. I can't imagine
> how it could be written in the sources to point compiler it should be compiled
> with threading.

Actually, you remind me of something:

While we all usually think more or less of POV-Ray as being hard to modify
for multithreading, this is not really so for one big part of the code.  The
intersection tests (and bounding) are with a very few exceptions next to
independent of global variables and very well isolated within the code
already.  So one could restrict threading to intersection tests and keep
multiple intersection stacks.  Hand the data over to a thread doing the
texturing after all intersections for one pixel have been calculated.  This
would still allow things like radiosity to work as they should assuming only
one thread calculates textures.  Only finishes (and maybe media) would have
to be taken into account in the other threads.  While balancing the load
would be more difficult and depend a lot on the scene, it should be "easy"
to implement in the current codebase and yield reasonable results with two
or maybe even four threads.  Of course on real supercomputers it would be
next to useless, but on common desktop multiprocessor systems...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

in news:3d833d4b$1@news.povray.org Thorsten Froehlich wrote:

> While we all usually think more or less of POV-Ray as being hard to
> modify for multithreading,

How about microthreading?
http://www.eecs.umich.edu/~stever/pubs/isca99.pdf

There used to be a stackless version of Python that did microthreading
 http://www.stackless.com/
 http://willware.net:8080/uthread.html

Although I don't understand most of this kind of stuff there are some 
aspects to it that made me wonder, would it be possible to do such a thing 
to POV-Ray and if so would it be usefull

Ingo

Post a reply to this message

On Sat, 14 Sep 2002 15:44:43 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> While we all usually think more or less of POV-Ray as being hard to modify
> for multithreading, this is not really so for one big part of the code.  The
> intersection tests (and bounding) are with a very few exceptions next to
> independent of global variables and very well isolated within the code
> already.

Your idea finally convinced me that uv coordinates in parametric object are
not holded as best as it could.

> While balancing the load
> would be more difficult and depend a lot on the scene, it should be "easy"
> to implement in the current codebase and yield reasonable results with two
> or maybe even four threads.

Are there such plans for 4.0?

ABX

Post a reply to this message

In article <Xns### [at] povrayorg> , ingo <ing### [at] tagpovrayorg>
wrote:

> How about microthreading?

Well, what is presented in the paper sounds very much like a variant of the
*T machine developed at MIT in the early 1990s and as implemented in the
88110MP (they called what they created microthreads as well).  The catch is
that like all fine grain threading architectures it requires hardware
support because the "problem" creating fine grain threads without hardware
switching support is that the required frequent context switching will eat
all of the possible performance gain.

    Thorsten


* Sadly, the project was completed in the pre-WWW days and thus not much can
be found online these days...
<http://www.wikipedia.com/wiki/Motorola_88000>


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message