 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://hardware.slashdot.org/comments.pl?sid=2346334&cid=36867000
This particular post on slashdot was interesting. Mental Ray can use the GPU
and throws thousands of threads at it mostly due to waiting for elements in main
memory. How feasible is this for Povray?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> http://hardware.slashdot.org/comments.pl?sid=2346334&cid=36867000
>
> This particular post on slashdot was interesting. Mental Ray can use the GPU
> and throws thousands of threads at it mostly due to waiting for elements in main
> memory. How feasible is this for Povray?
>
>
>
There is a big problem. When you programm a GPU, you can't use the same
code for an ATI, an nVidia or an Intel one.
WHO have 10 graphic cards in his computer?
Also, to my knowlege, GPU still don't do double precision FP operations,
only single precision. POV-Ray require double precision for most of it's
computations, hardware supported triple or quadruple presision would be
nice.
GPUs are made to work only on triangles, POV-Ray use several,
non-teselated, primitives. You'd only be able to render triangles,
meshes and bicubic parches on the GPU.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ATI and NVidia GPUs have had 64-bit float since 2008. I would imagine parts of
Povray could be rewritten with OpenCL to take advantage of these things. GPUs
are fairly general purpose nowadays.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://raytracey.blogspot.com/2011/04/kajiyas-scene-from-rendering-equation.html
No polygons there, just spheres. They recreated in real-time on a GPU the
original scene from Kajiya's paper on the rendering equation and a path tracer.
Even blender got its own fast GPU path tracer these days, though it certainly
uses polygons:
http://blenderartists.org/forum/showthread.php?216113-Brecht-s-easter-egg-surprise-Modernizing-shading-and-rendering
last pages show incredible stuff...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> http://raytracey.blogspot.com/2011/04/kajiyas-scene-from-rendering-equation.html
>
> No polygons there, just spheres. They recreated in real-time on a GPU the
> original scene from Kajiya's paper on the rendering equation and a path tracer.
>
> Even blender got its own fast GPU path tracer these days, though it certainly
> uses polygons:
>
>
http://blenderartists.org/forum/showthread.php?216113-Brecht-s-easter-egg-surprise-Modernizing-shading-and-rendering
>
> last pages show incredible stuff...
>
>
There is still the isue that, if you don't have an nVidia chip with
CUDA, it won't work at all...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <aze### [at] qwerty org> wrote:
> > http://raytracey.blogspot.com/2011/04/kajiyas-scene-from-rendering-equation.html
> >
> > No polygons there, just spheres. They recreated in real-time on a GPU the
> > original scene from Kajiya's paper on the rendering equation and a path tracer.
> >
> > Even blender got its own fast GPU path tracer these days, though it certainly
> > uses polygons:
> >
> >
http://blenderartists.org/forum/showthread.php?216113-Brecht-s-easter-egg-surprise-Modernizing-shading-and-renderin
g
> >
> > last pages show incredible stuff...
> >
> >
>
> There is still the isue that, if you don't have an nVidia chip with
> CUDA, it won't work at all...
Incorrect. ATI/AMD users can install Stream SDK for OpenCL to work.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 25.07.2011 19:02, schrieb jhu:
> ATI and NVidia GPUs have had 64-bit float since 2008. I would imagine parts of
> Povray could be rewritten with OpenCL to take advantage of these things. GPUs
> are fairly general purpose nowadays.
>
>
Note that support for double precision floating point types is *not*
part of the OpenCL 1.1 specification but just an optional implementor
specific feature.
As a matter of fact AMD's OpenCL implementation (BTW meanwhile called
"APP" and no longer "Stream") does not support doubles neither does
NVidia's.
The only platform that does actually support 64-bit floats is Intels
OpenCL SDK - and it's JIT compiler does in fact an amazing job in
automatically vectorizing and optimizing for SSE2/3/4 registers
depending on the used platform - but obviously it does not support any GPU.
So the funny situation ATM: if you have an AMD processor you'll need the
Intel OpenCL SDK installed to get support for doubles within OpenCL for
your AMD CPU and exactly zero OpenCL platfoms support 64bit floats for
GPU's.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.07.2011 06:53, schrieb Ive:
> Note that support for double precision floating point types is *not*
> part of the OpenCL 1.1 specification but just an optional implementor
> specific feature.
> As a matter of fact AMD's OpenCL implementation (BTW meanwhile called
> "APP" and no longer "Stream") does not support doubles neither does
> NVidia's.
> The only platform that does actually support 64-bit floats is Intels
> OpenCL SDK - and it's JIT compiler does in fact an amazing job in
> automatically vectorizing and optimizing for SSE2/3/4 registers
> depending on the used platform - but obviously it does not support any GPU.
> So the funny situation ATM: if you have an AMD processor you'll need the
> Intel OpenCL SDK installed to get support for doubles within OpenCL for
> your AMD CPU and exactly zero OpenCL platfoms support 64bit floats for
> GPU's.
>
Just a quick update:
The brand new (from today) AMD OpenCL driver does support 64bit floats
for GPU's. And it even works, just wrote a simple program that makes use
of it.
But still no support for double from AMD for its own CPU's.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 25.07.2011 09:49, schrieb jhu:
> http://hardware.slashdot.org/comments.pl?sid=2346334&cid=36867000
>
> This particular post on slashdot was interesting. Mental Ray can use the GPU
> and throws thousands of threads at it mostly due to waiting for elements in main
> memory. How feasible is this for Povray?
With the (very recent) release of the first (GP)GPU supporting both
64-bit floats and recursion, adapting POV-Ray for (those) GPUs might
actually become technically feasible soon (though it still may take
quite some time before it hits the dev team's top priorities list).
An open question would still be that of performance, which will mainly
depend on how well the software architecture fits with the "Extreme
SIMD" ("Single Instruction Multiple Data") hardware architecture. We
might see a positive surprise there, though it could just as well turn
out a big disappointment.
In any case I think the easiest-to-implement approach (and hence the
best approach for official POV-Ray) at GPU support would be to implement
network rendering first (it's high up on the ToDo list anyway), and then
treat the GPU as a separate rendering node.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 04.08.2011 23:12, schrieb clipka:
> An open question would still be that of performance, which will mainly
> depend on how well the software architecture fits with the "Extreme
> SIMD" ("Single Instruction Multiple Data") hardware architecture. We
> might see a positive surprise there, though it could just as well turn
> out a big disappointment.
>
Guess I can answer this one as I was just curious (people from the
luxrender project did claim a 60x speedup) and did implement a simple
raytracer with a static scene and did follow Intel's recommendation of
doing warmup runs before actually measuring the runtime. Here are the
results for the raw calculation time without scene initialization:
CPU using 8 threads
fps 33.39695
2.9942 seconds
OpenCL CPU using 8 worker units
Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
2.8005 seconds
OpenCL GPU using 18 worker units
Cypress
1.7871 seconds
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
