> I think you are right on this. Thats just how the render-pipeline goes into
> "OpenCL".
>
> Let me say that its just a old missconception to say that GPU's "can only render
> simple stuff". This was true in the past but let me show you this video to
> correct your opinion to the opposite.
>
> https://www.youtube.com/watch?v=ByJGkSzh4eQ
>
> In fact "modelling and rendering" in REAL-TIME of several Diamonds, including
> transparence, refraction and REAL dispersion is "state-of-the-art". As you can
> see in this video.

It's only rendering a triangle mesh though. POV is far more complex than 
that. I have not see a GPU raytracer that can render many different 
mathematical primitives at the same time. *That* requires an awful lot 
more work, and won't be anywhere near as optimised as a raytracer that 
renders just meshes or just isosurfaces etc.

Post a reply to this message

> 1. INTRODUCTION  TO  BIDIRECTIONAL  PATH  TRACING     &  ITS  IMPLEMENTATION
> USING  OPENCL
>    TAKAHIRO  HARADA          (AMD)   SHO  IKEDA  (RICOH)   SYOYO  FUJITA
>    (LTE)
> BDPT
> IntegraJon  of  BidirecJonal  Path  Tracing  to  the Engine  (Harada,  5min)
>
>
http://fr.slideshare.net/takahiroharada/introduction-to-bidirectional-path-tracing-bdpt-implementation-using-opencl-ced
> ec-2015
>
> All the needed informations are out there reday to be implemented by people who
> know where they want to go (and have enough time and resources :-).

Have you ever had a go at coding a raytracer before?

Post a reply to this message

Am 04.01.2016 um 22:55 schrieb Theogott:

> Some years ago we had a POV-Ray version using SSE. WHY?
> For a few (100% ?) more speed in some scenes.

Actually that's SSE2, and we still have it.

> 100% more speed is completely uninteresting when we talk about OpenCL and GPU's.
> We start here with 1000% faster and we go to 30 times faster if you have a "two
> GPU graphics card". For actually 350 EUR from Ebay (like my HD 7990).

You need to put that into perspective, however, with the development
effort that goes with it.

Making use of the SSE2 instruction set extensions for x86 CPUs is just a
matter of flipping a switch in the compiler settings. Making use of GPUs
might require a rewrite of major portions of the code.

Just look at how long it took to get the multi-core support released.


I'm not saying GPU support is a bad idea. I'm not saying POV-Ray will
never go down that road. All I'm saying is that (1) it'll be an
assload(*) of work to get there, and (2) please give us a break now and
cease your attempts to campaign for it.

Your message has been received, there's little to nothing left you or
anyone could add to the discussion that would speed things up, and the
whole topic is pretty frustrating for the developers (at least for me),
because all we can do about it -- time and again, whenever the issue
pops up -- is say, yup, that would really be neat to have, but don't
expect any visible progress in that direction any time soon, because...
and then give you a list of whatever obstacles we currently consider the
most adverse to get there.

Some obstacles have been addressed in recent times by the GPU
manufacturers. Others are more fundamental; and while potential
solutions have been found thanks to an improved understanding of those
issues, and I reckon that there are no real show stoppers along the road
anymore, these fundamental obstacles do leave us with that
aforementioned assload of work required to get around them.


I might also add that the very first step of that assload of work will
be cleanup and modularization of the existing code, which is something
that's already being done as we speak, for plenty of other reasons.


(* That's "ass" as in "donkey", mind you ;))

Post a reply to this message

Am 04.01.2016 um 22:59 schrieb Theogott:

> All the needed informations are out there reday to be implemented by people who
> know where they want to go (and have enough time and resources :-).

And there, in parentheses, you already mention the crux of the matter.

Really, please cut it out. We know it's being done. We know people want
it in POV-Ray. Heck, we ourselves want it in POV-Ray. And believe us,
we've already done a bit of casual research on the matter before, and
will be quite able to google up papers ourselves once we feel we're
ready to dig into the details.

Post a reply to this message

Yes, i just use the chance to spread a little bit of the newest trends.
If i would have higher mathematical knowledge, i would better understand the
details.

For example this, here are even downloads on the site.

https://mediatech.aalto.fi/publications/graphics/GPT/

What is POV-Ray?

To the end user its a GUI with a SDL. A easy to use SDL.
Something that i have not seen somewhere else.

Actually its often used for technical visualisation, because the POV-Ray
SDL-Scruipt can easily be automatically generated by other programs.

People who just don't like "visual Modeller programs" of all sorts choose
POV-Ray.

Whats at the back-end (Meshes or primitives) does not really interest the end
user so much.
At the end the end user doesn't know if there are Meshes at the beack-end or
primitives. And normally i would say that all Primitives can be converted
somehow to Meshes, at least i think they do it in Cinema 4D this way.

Going from there the question is, if it would be possible to take the POV-SDL

example Luxrays or this thing here.

Then just add an second "Render Path" ("unbiased path"). Which would then have
support for GPU.

Luxray has good developers, they swim in one direction, they don't have a
comparable good SDL like POV. But they have other features, for example support
for OpenCl.

So if it weould be possible to convert the POV-Ray results to meshes ... then
render it with Luxrays you would have the best of both worlds.

If i had more knowledge how all this works, maybe I'de just think of making such
an "POV-Like Editor" that will just transfer the POV-SDL into the Luxray
"export-code".

We experience at this time large changes in this market segment. Many Freeware
renderers are dead.
And POV-Ray is one of those that is still left. For so many years since the
AMIGA.

I remember ... i had it already at the Amiga. But when i visit all those sites
and the Newsgroups there is not so much life like before.

And it does not really look like its increasing.
So the question is, if it would not be an idea to go together with others.
That have the same problem.

Post a reply to this message

Am 05.01.2016 um 23:06 schrieb Theogott:

> Whats at the back-end (Meshes or primitives) does not really interest the end
> user so much.

... until it causes artifacts.

> At the end the end user doesn't know if there are Meshes at the beack-end or
> primitives. And normally i would say that all Primitives can be converted
> somehow to Meshes, at least i think they do it in Cinema 4D this way.

We had /this/ topic just a couple of days ago: Converting the entire set
of primitives supported by POV-Ray to meshes isn't trivial either. In
some cases because it is simply difficult to convert the shape to a mesh
in the first place; this is the case for isosurfaces, fractals, and
possibly a few others. In other cases it is a matter of precision: How
much faceting is acceptable in the geometry of a sphere, for example?
There is no clear answer to that -- it depends on what role and size it
has in the render, and/or what CSG operations it participates in.

And then there is the shading that would need to be ported to whatever
render engine would be used instead, from the reflection model to the
legion of patterns supported by POV-Ray.


And once again the whole project would first need a lot of work towards
more modularization of the code. Which, as I may re-iterate, is
currently being worked on.

Post a reply to this message

What is the benefit of having GPU rendering rather than just going to 
the store and buying yourself a faster processor? Are GPUs inherently 
better at this stuff than CPUs?


Mike

Post a reply to this message

On 1/6/2016 5:03 AM, Mike Horvath wrote:
> What is the benefit of having GPU rendering rather than just going to
> the store and buying yourself a faster processor? Are GPUs inherently
> better at this stuff than CPUs?
>

I think the benifit is that the GPU is sitting idle, doing nothing when 
it could be working.
I think it just rankles that all that processing power is going to waste.


-- 

Regards
     Stephen

Post a reply to this message

Am 06.01.2016 um 06:03 schrieb Mike Horvath:
> What is the benefit of having GPU rendering rather than just going to
> the store and buying yourself a faster processor? Are GPUs inherently
> better at this stuff than CPUs?

The benefit is that GPUs can give you far more floating point operations
per buck and second than CPUs.

The drawback is, that's only true as long as you're performing the same
sequence of operations on a vast number of data points in parallel. As
soon as any data points need special treatment, the other data points'
computations need to be stalled. So programs need to be written in a
matter that minimizes such special handling.

Post a reply to this message

> What is the benefit of having GPU rendering rather than just going to
> the store and buying yourself a faster processor? Are GPUs inherently
> better at this stuff than CPUs?

For very simple algorithms that run a huge number of times on slighty 
different input parameters, a GPU can often be several orders of 
magnitude faster than a CPU. For example I ported a very simple 
path-tracer from CPU to GPU, it ended up about 1000x faster as it is 
perfectly suited to running on a GPU. There's a short video of it in 
action here:

https://www.youtube.com/watch?v=rXQa5kHspFk

The issue is with more complex real-world applications, they need to be 
broken down into "bitesize" chunks that a GPU can run efficiently, and 
between each "chunk" being run on the GPU, some amount of processing is 
likely required to prepare. Often not easy from a conceptual point of 
view, and there is no guarantee that the resulting application will be 
much faster than the original CPU-only version.

Post a reply to this message