 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Why you say no when CPU-GPU combos are been used in several applications
like I listed, ray-tracing or there are trends to use this combo to
solve problems so I think is a yes, maybe is in very early stages but
this is tending to evolve and could become common ground and open
source. Why are you so negative about it? What would make you think in a
yes?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Saul Luizaga <sau### [at] netscape net> wrote:
> Why you say no when CPU-GPU combos are been used in several applications
> like I listed, ray-tracing or there are trends to use this combo to
> solve problems so I think is a yes, maybe is in very early stages but
> this is tending to evolve and could become common ground and open
> source.
The GPU can be only used for certain task. It's not a generic processor
like the CPU is. There are other tasks which are very inefficient and
difficult to do with the GPU. And of course there are tasks which are
simply impossible to perform with the GPU.
Not all tasks related to computer graphics can be performed with the
GPU. The GPU is specialized in a certain type of calculations.
One feature of GPUs is that they are good at making the same calculations
in parallel. For example, if you are applying a filter to an image the
GPU is superb for this. That's because the exact same filter can be
applied to every single pixel of the image. It's the one and same task
performed over a set of data.
Raytracing isn't such a task, though. Rays may or not get reflected and
refracted, split into two, they may or may not be used for shadow testing,
they may or may not be used to sample media, a texture may or may not be
evaluated at an intersection point... It's hard to do these things with
a GPU.
Another killer is that GPUs don't support recursion, while raytracing
obviously requires it.
> Why are you so negative about it?
I'm not negative. I'm realist. I don't like to raise false hope.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 2. Even the stuff they could be used for, they can't, because not all
> features use the same floating point sizes, and no card currently
> supports 64-bit floating point. This creates two problems. A) POVRay
> would be limited to using one those floating point processes that "do"
> use the same sizes as it does, for 32-bit systems, and b) for the 90% of
> us who are *probably* at this point running on 64-bit processors
32-bit/64-bit CPUs have nothing to do with floating point. Your old
Pentium II can do 64-bit floating point calculations.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Your old
> Pentium II can do 64-bit floating point calculations.
The 80386 can do 64-bit floating point calculations (if it has the
80387 FPU).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 23 Jan 2008 16:53:52 -0500, Warp wrote:
> The 80386 can do 64-bit floating point calculations (if it has the
> 80387 FPU).
Arguably, the 80386 can't do 64-bit floating-point calcuations, because
that was the function of the optional 80387 (or Weitech Math
Coprocessor). The 386 just handed those operations off if the copro was
present.
I've still got a 386 that I bought for college that has the optional FPU
installed in it...
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson <nos### [at] nospamcom> wrote:
> Arguably, the 80386 can't do 64-bit floating-point calcuations, because
> that was the function of the optional 80387
1) The 80386 *can* perform 64-bit (and 128-bit and 1024-bit if you want)
floating point calculations. Not just as fast as the 80387 co-processor.
2) When I said "80386" I was referring to the architecture and not to
the CPU per se. Arguably the 80387 co-processor is part of the overall
architecture (hence the numbering).
The 286 architecture also had a 287 co-processor, but I'm not sure if
it supported 64-bit floating point numbers. Maybe.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> The 286 architecture also had a 287 co-processor, but I'm not sure if
> it supported 64-bit floating point numbers. Maybe.
It seems that it did. In fact, the very first x87 co-processor, the
8087 did support 64-bit and even 80-bit FPU calculations.
So, arguably, a 8086 with a 8087 co-processor can perform 64-bit floating
point artithmetic in hardware. And we are talking about a 16-bit architecture
here.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 23 Jan 2008 18:19:02 -0500, Warp wrote:
> Jim Henderson <nos### [at] nospamcom> wrote:
>> Arguably, the 80386 can't do 64-bit floating-point calcuations, because
>> that was the function of the optional 80387
>
> 1) The 80386 *can* perform 64-bit (and 128-bit and 1024-bit if you
> want)
> floating point calculations. Not just as fast as the 80387 co-processor.
Oh, right, I had forgotten that the FPU was really there to make it
faster...
> 2) When I said "80386" I was referring to the architecture and not to
> the CPU per se. Arguably the 80387 co-processor is part of the overall
> architecture (hence the numbering).
Fair enough...
> The 286 architecture also had a 287 co-processor, but I'm not sure if
> it supported 64-bit floating point numbers. Maybe.
Well, with an arbitrary-precision library, I'll bet it could. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <479796ce$1@news.povray.org>,
nic### [at] gmailisthebestcom says...
> > 2. Even the stuff they could be used for, they can't, because not all
> > features use the same floating point sizes, and no card currently
> > supports 64-bit floating point. This creates two problems. A) POVRay
> > would be limited to using one those floating point processes that "do"
> > use the same sizes as it does, for 32-bit systems, and b) for the 90% o
f
> > us who are *probably* at this point running on 64-bit processors
>
> 32-bit/64-bit CPUs have nothing to do with floating point. Your old
> Pentium II can do 64-bit floating point calculations.
>
Oh, sure, lets nit pick... And we where talking about GPU, not CPU/FPU.
The point that always comes up and, for which what the main processor
can do, is irrelevant, is that the type of floating point done on the
GPU isn't usable via POVRay, no matter what type of system its on.
--
void main () {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <47973c65@news.povray.org>, sau### [at] netscapenet says...
> Why you say no when CPU-GPU combos are been used in several applications
> like I listed, ray-tracing or there are trends to use this combo to
> solve problems so I think is a yes, maybe is in very early stages but
> this is tending to evolve and could become common ground and open
> source. Why are you so negative about it? What would make you think in a
> yes?
>
As Warp says, its not really designed for recursive raytracing. There
**are** hybrid applications that do fairly decent results, which
probably do use it to speed things up a bit, **however** those systems
are intended for production level systems, where speed is considered
more important than realism. Since POVRay's primary goal is to generate
the more realistic physical model possible, and short cuts that could be
used to produce a movie, or the like, by side stepping, short cutting,
or even ignoring, certain methods, in favor of speed, are "not" the
intended goal here. Mind you, I wouldn't mind some of those short cuts,
since its damn near impossible to do some things the "right" way, and
certainly not in a sane span of time. But, short of adding those in as
optional, so those in "production" level fields could use them, while
leaving the normal methods intact, there isn't a benefit to the intent
of the project to do that.
About half the people here would scream bloody murder and try to beat
you to death with a checker plane if you tried to add shortcuts, never
mind that there aren't a lot of free rendering systems that are as good,
and also use those short cuts. Most of the other half would still be
busy sharpening the edges of their triangle primitives, just in case
your suggestion did break the physical based systems already in there.
lol But, I think you see what I am getting at. Even if some of us would
find it useful to take short cuts, its *not* what the program is
supposed to be designed for, and what it *is* intended for isn't
functionally possible in current GPUs.
--
void main () {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
