Chambers <ben### [at] pacificwebguycom> wrote:
> Perhaps if 
> Intel surprises everyone, and releases their next graphics chip as a 
> double precision FP monsters, we'd be able to take advantage of that, 

  Exactly how would it be different from current FPUs?

-- 
                                                          - Warp

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> _theCardinal wrote:
> > Ben Chambers <ben### [at] pacificwebguycom> wrote:
> >> No good, they're only single precision.  Plus, each shader unit would
> >> need access to the entire scene file, which would be a pain in the a**
> >> to code.
> >>
> >> ...Chambers
> >
> > According to the CUDA programming guide published by NVidia the GPGPU
> > architecture is as competent as any 32 bit processor.  More precise
> > computations can be simulated using multiple registers for a computation
> > instead of a single register if my memory serves - so I seriously doubt
> > this is a serious obstacle.
>
> But double precision is actually 64bit.  Until recently (I don't
> remember exactly which model), NVidia didn't even do full 32bit FP (that
> is, single precision), but only 24.  POV-Ray, for the last dozen years,
> has done 64bit FP (double precision), as the extra accuracy is necessary
> for the types of computations it does.
>
> Sure, you can simulate it in the same way you can use two integer units
> to simulate a fixed point number, but the result is slow.  Perhaps if
> Intel surprises everyone, and releases their next graphics chip as a
> double precision FP monsters, we'd be able to take advantage of that,
> but the current ATI / NVidia cards aren't up to the task of dealing with
> POV-Ray.
>
> > The major difficulty involved would be preparing the pov-ray source to run
> > efficiently on a SIMD architecture - native code may run out of the box
> > through the provided compiler, but the results would be poor at best
> > without optimization to take advantage of the particular memory hierarchies
> > involved.
>
> Once the 3.7 source is out, it should be much easier, as the major task
> is simply fitting it to a parallel paradigm.  Having already done that,
> porting to different parallel architectures should be trivial (relative
> to the original threading support, that is).
>
> --
> ...Ben Chambers
> www.pacificwebguy.com

Few things:

"But double precision is actually 64bit."
To be technical the number of bits used for a double is implementation
dependent.  The requirement is simply that a float <= double.  It is up to
compiler to decide how to interpret that.  Using double in lieu of float
simply indicates the desire for additional precision - not the requirement
(in C and C++).  Hence it is impossible in general to say povray is using
64 bits.  See: The C++ Programming Language (TCPL) 74-75.

Compilers may have more than a few techniques to simulate 64 bit computation
on a 32 bit architecture, but I am not experienced enough in compiler design
to state them within reasonable doubt.  Its worth noting that the time lost
in doing 2 ops instead of 1 is easily regained in shifting from 1-2
processors to an array of processors, so this is not a concern provided the
utilization of the array is sufficiently high.

CUDA is a new beast - designed for 8800 or later generation cards by NVidia.
 This means that the vast majority of cards in use today do not support it -
and probably won't for the next 2-3 years.  According to the specification I
read the registers are full 32 bit, not 24 as in earlier cards.  For more
detailed information google CUDA and browse the documentation provided
along with the SDK.

I would like to clarify that a dual-processor design is not likely to share
much in common with a SIMD (single instruction multiple data) architecture.
 In particular - reaching optimal utilization when sets of processors are
required to share the same instruction set is not terrible easy, this
requirement doesn't exist at all for a dual-core architecture (and is one
of the reasons it moved into consumer systems).  General ray-tracing does
show great potential though, since its intuitively rare to have an image
where the number of rays to evaluate varies rapidly over the image.
(Refracting through a 'bag of marbles' would be a good counterexample
though - a small shift in direction would wildly vary in the number of rays
to computer.  I doubt there is any tractable deterministic method to check
if this is the case though)

Personally I am less concerned with the usefulness of the implementation
that in its experimental value.

Thanks,

Justin

Post a reply to this message

"Q: Does CUDA support Double Precision Floating Point arithmetic?

 A: CUDA supports the C "double" data type.  However on G80
    (e.g. GeForce 8800) GPUs, these types will get demoted to 32-bit
    floats.  NVIDIA GPUs supporting double precision in hardware will
    become available in late 2007."
Source: NVidia CUDA release notes version 0.8.

My guess is that where NVidia goes ATI has already gone or is not far
behind.

Justin

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
> > Perhaps if
> > Intel surprises everyone, and releases their next graphics chip as a
> > double precision FP monsters, we'd be able to take advantage of that,
>
>   Exactly how would it be different from current FPUs?
>
> --
>                                                           - Warp

There are 2 typical variants of FPU around right now - 32 bit and 64 bit,
matching the type of processor they are included on.  Having a 64 bit FPU
is necessary for doing 64 bit arithmetic in hardware - but is not
sufficient.  It would also require a 64 bit operating system such as
windows XP x64, vista 64-bit, or a version of Unix compiled for 64 bit
systems.  All mainstream 64 bit processors can run in a limited 32-bit mode
to back-support 32 bit execution, if this is the case the precision
available is still only 32 bit in hardware.

Software packages exist for manipulating floating point data in various
extended formats - but as Mr. Chambers mentioned they are not as efficient
as hardware support.

Justin

Post a reply to this message

_theCardinal wrote:
> There are 2 typical variants of FPU around right now - 32 bit and 64 bit,
> matching the type of processor they are included on.  Having a 64 bit FPU
> is necessary for doing 64 bit arithmetic in hardware - but is not
> sufficient.  It would also require a 64 bit operating system such as
> windows XP x64, vista 64-bit, or a version of Unix compiled for 64 bit
> systems.  All mainstream 64 bit processors can run in a limited 32-bit mode
> to back-support 32 bit execution, if this is the case the precision
> available is still only 32 bit in hardware.

Wrong, unless you meant to write CPU.

FPUs on x86 as well as virtually all non-embedded-use-only processors
support at least 64-bit floating point precision in hardware..

	Thorsten, POV-Team

Post a reply to this message

_theCardinal <_the### [at] yahoocom> wrote:
> There are 2 typical variants of FPU around right now - 32 bit and 64 bit,
> matching the type of processor they are included on.  Having a 64 bit FPU
> is necessary for doing 64 bit arithmetic in hardware - but is not
> sufficient.  It would also require a 64 bit operating system such as
> windows XP x64, vista 64-bit, or a version of Unix compiled for 64 bit
> systems.  All mainstream 64 bit processors can run in a limited 32-bit mode
> to back-support 32 bit execution, if this is the case the precision
> available is still only 32 bit in hardware.

  You have a serious confusion there, mister.

  How do you think POV-Ray can use 64-bit floating-point numbers
*in hardware* even with 32-bit computers?

-- 
                                                          - Warp

Post a reply to this message

_theCardinal <_the### [at] yahoocom> wrote:
> "But double precision is actually 64bit."
> To be technical the number of bits used for a double is implementation
> dependent.  The requirement is simply that a float <= double.  It is up to
> compiler to decide how to interpret that.  Using double in lieu of float
> simply indicates the desire for additional precision - not the requirement
> (in C and C++).  Hence it is impossible in general to say povray is using
> 64 bits.  See: The C++ Programming Language (TCPL) 74-75.

  That may be true *in theory*. In practice it's not compiler-dependent
but hardware-dependent. Since basically all existing hardware (including
non-intel one) uses IEEE 64-bit double-precision floating point numbers,
that's what all compilers use too. It wouldn't make sense using anything
else.

  So yes, you can say *for sure* that POV-Ray uses 64-bit floating point
numbers. I challenge you to mention a computer where POV-Ray runs and where
'double' is not 64 bits long.

> Compilers may have more than a few techniques to simulate 64 bit computation
> on a 32 bit architecture, but I am not experienced enough in compiler design
> to state them within reasonable doubt.

  You have a serious misconception about FPUs and double-precision floating
point numbers.
  Compilers don't need to simulate anything: Intel FPUs have supported 64-bit
floating point numbers since probably the 8087. That has nothing to do with
the register size of the CPU, as the FPU is quite independent of it.

>  Its worth noting that the time lost
> in doing 2 ops instead of 1 is easily regained in shifting from 1-2
> processors to an array of processors, so this is not a concern provided the
> utilization of the array is sufficiently high.

  1) There's no need to do "2 ops instead of 1" when speaking about 64-bit
floating point numbers.
  2) Even if it was, it's not possible to perform floating point arithmetic
with a larger floating point type by simply doing 2 operations instead of
the regular 1.

-- 
                                                          - Warp

Post a reply to this message

_theCardinal <_the### [at] yahoocom> wrote:
>  A: CUDA supports the C "double" data type.  However on G80
>     (e.g. GeForce 8800) GPUs, these types will get demoted to 32-bit
>     floats.  NVIDIA GPUs supporting double precision in hardware will
>     become available in late 2007."

  And my questiom is: When it supports 64-bit floating point numbers,
how will it be different from current FPUs?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> _theCardinal <_the### [at] yahoocom> wrote:
>>  A: CUDA supports the C "double" data type.  However on G80
>>     (e.g. GeForce 8800) GPUs, these types will get demoted to 32-bit
>>     floats.  NVIDIA GPUs supporting double precision in hardware will
>>     become available in late 2007."
> 
>   And my questiom is: When it supports 64-bit floating point numbers,
> how will it be different from current FPUs?

The most important difference probably is that the GPUs are closed 
products with no comprehensive specifications being available.  If you 
like to use them you have to use the proprietary SDKs provided by Nvidia 
and available only for the platforms they support (if you are lucky they 
offer a x86-linux version - usually working only in combination with 
their closed hardware drivers, if not it's Windows only).

I would strongly suggest anyone who is thinking about integrating 
something like that with POV-Ray to think twice about putting much work 
into a technology that is almost certainly outdated and forgotten within 
2-3 years.

Christoph

-- 
Views of the Earth: http://earth.imagico.de/
Images, include files, tutorials: http://www.imagico.de/
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> >   And my questiom is: When it supports 64-bit floating point numbers,
> > how will it be different from current FPUs?

> The most important difference probably is that the GPUs are closed 
> products with no comprehensive specifications being available.  If you 
> like to use them you have to use the proprietary SDKs provided by Nvidia 
> and available only for the platforms they support (if you are lucky they 
> offer a x86-linux version - usually working only in combination with 
> their closed hardware drivers, if not it's Windows only).

  I'm also wondering about what advantages there could be compared to
current FPUs.

  There are obvious advantages to the graphics which the graphics card
itself renders. Currently vertex and pixel shaders have no or very little
floating point math support, and adding that support will probably allow
more stunning graphics effects to be achieved.

  However, how could POV-Ray benefit from this? What will this offer for
POV-Ray that current FPUs don't?

  Besides, there will probably be data transfer overhead. Games can simply
upload their vertex and pixel shader code into the graphics card and then
let the graphics card do what they do. Games don't need the results back.

  POV-Ray does need the results of the calculations back. How is it going
to do that? And what advantages will this bring to it compared to the
current regular usage of the FPU (which has in practice no overhead)?

  Sure, some graphics software are using modern graphics cards to perform
eg. image transformations and filters. But that's a much simpler task.
The software simply uploads a shader to the graphics card, tells it to
apply it to a texture, and the graphics card does that. It's a simple task
which the graphics card can do all by itself. When it's done, the software
can simply read the resulting image.
  This is a bit different from what POV-Ray does. POV-Ray can't work by
simply applying a shader to an image. POV-Ray is a raytracer.

-- 
                                                          - Warp

Post a reply to this message