 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have just submitted my result from the Luxmark Test to the site.
The results were:
Scores were:
1208 - for 12 Intel CPU-Cores a' 3.3 GHz.
27800 - for my HD 7990 Graphics card.
In short: The rendering speed of a CPU of these days is within the
measurement-tolerance of an actual (not so actual ... HD 7990) graphics card.
This simple fact makes the use of GPU-Rendering an interesting topic as i see
it. I have examined Luxrender the last time. They do NOT have currently such a
nice rendering SDL like POV-Ray.
To use it, it needs wether Phyton or Blender and its to some degree more
difficult to get it realkly working. However seeing it, or for example "Blender
Cycles" render scenes in 22 seconds using the GPU (via OpenCL) looks funny.
Luxmark - OpenCL rendering Speed-Test.
http://www.luxmark.info/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> In short: The rendering speed of a CPU of these days is within the
> measurement-tolerance of an actual (not so actual ... HD 7990) graphics card.
...
> They do NOT have currently such a
> nice rendering SDL like POV-Ray.
That is not a coincidence.
GPUs are excellent for writing a simple raytracer that runs very fast.
By simple, I mean only supporting one type of simple shape (eg mesh,
isosurface, sphere), no CSG, no general procedural textures, only one or
two types of light in a scene etc. The point is the code that is run on
the GPU is very specific, and the GPU hardware then excels at running
this exact code millions of times on different data.
However if you wanted to implement an SDL like POV-ray's, you would need
code to handle every possible primitive shape (each shape needs it own
intersection algorithm), every possible procedural texture, CSG, shadow
and lighting algorithms for every possible finish and light type etc.
Such a large bit of code, where each time it is "run", a different small
portion is actually executed, is not well suited to a GPU at all.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scott com> wrote:
> > In short: The rendering speed of a CPU of these days is within the
> > measurement-tolerance of an actual (not so actual ... HD 7990) graphics card.
>
> ...
>
> > They do NOT have currently such a
> > nice rendering SDL like POV-Ray.
>
> That is not a coincidence.
>
> GPUs are excellent for writing a simple raytracer that runs very fast.
> By simple, I mean only supporting one type of simple shape (eg mesh,
> isosurface, sphere), no CSG, no general procedural textures, only one or
> two types of light in a scene etc. The point is the code that is run on
> the GPU is very specific, and the GPU hardware then excels at running
> this exact code millions of times on different data.
>
> However if you wanted to implement an SDL like POV-ray's, you would need
> code to handle every possible primitive shape (each shape needs it own
> intersection algorithm), every possible procedural texture, CSG, shadow
> and lighting algorithms for every possible finish and light type etc.
> Such a large bit of code, where each time it is "run", a different small
> portion is actually executed, is not well suited to a GPU at all.
I don't think it's totally out of the question to write a GPU-based render
engine that does support plenty of shapes, procedural textures, etc. The
challenge there is to bunch sufficiently similar rays together -- the buzzword
being "ray coherence". This is comparatively easy for 1st-level rays by just
bunching up rays for adjacent pixels, but 2nd- or 3rd-level rays will become
increasingly incoherent, so for efficient computation it will probably be
required to postpone their computation until rays with sufficiently similar
origin and direction have accumulated and are ready to be traced in a batch.
You will probably end up with an architecture that smashes up the whole ray
tracing process into small steps -- possibly even into multiple steps per trace
level, such as separating intersection testing from shading computations --,
introducing buffer structures to both pass data from one step to the next and
re-consolidate it into coherent batches.
The problem with POV-Ray, however, is that its internal architecture is still
comparatively monolithic, and therefore does not lend itself to being smashed
into pieces that easily.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Some years ago we had a POV-Ray version using SSE. WHY?
For a few (100% ?) more speed in some scenes.
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 don't need to invest a lot of money into a 16 Core CPU, it will not halp you
as much as half the money in a GPU.
Its rather that you can render more complex scenes that you would never render
without a CPU.
I think this video shows that using the GPU is in the future in fact the place
where raytracing has to be done.
What is OpenCL ?
https://www.youtube.com/results?search_query=opencl+opencl
Take a look on this Open Source Rendering programm, even the source code is
available. OpenCL is the way to go.
https://www.youtube.com/watch?v=iZ56eHKz6Ts
You can go to this web-site. Read the source code. And think how you could
implement it. Maybe you just make triangles out of the "primitives" before you
render?
Take a look at the future of GPU's.
https://www.youtube.com/watch?v=Tb7ZYSTYHbw
Rendering with CPU will soon be dead.Something for a few leftovers.
Its just a question of brute force.
We soon get GPU's with several thousands of (slower, but more) Cores that do
render completely in parallel, every pixel!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Let me add this link.
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 :-).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
