|
 |
scott wrote:
>>> Hopefully someone will try its hand at least to speed up povray
>>> triangle handling.
>>>
>> It would be extremely difficult to handle triangles, and e.g. spheres
>> or isosurfaces consistently if you use different ways of computing them.
>
> Yes, unless you do the whole lot on the GPU you're going to get bogged
> down with CPU<>GPU communications.
>
> If you converted POV to run on the GPU then it would take a huge amount
> of work and would no longer be as portable as it is today.
But would be much faster! Take a look here:
http://vimeo.com/8487987
it's an experimental and limited port of the open-source unbiased
renderer Luxrender to OpenCL. Experimental or not and OpenCL being very
early and not mature enough, it already boasts an incredible boost over
CPU-only code!
Can you imagine what povray could do comparatively without getting
boiled down by unbiased techniques?!
CUDA would limit portability, but not OpenCL.
> AFAIK the
> POV team don't want either of those two things so it's not going to happen.
So that means povray will be the slowest raytracer around, is that
right? Good Lord, it's sad that 3.7 is not out yet and it was once one
of the fastest and first raytracers to go multicore... now it's being
beaten by unbiased renderers!
Post a reply to this message
|
|
|
|
nemesis wrote:
> scott wrote:
>>>> Hopefully someone will try its hand at least to speed up povray
>>>> triangle handling.
>>>>
>>> It would be extremely difficult to handle triangles, and e.g. spheres
>>> or isosurfaces consistently if you use different ways of computing them.
>>
>> Yes, unless you do the whole lot on the GPU you're going to get bogged
>> down with CPU<>GPU communications.
>>
>> If you converted POV to run on the GPU then it would take a huge
>> amount of work and would no longer be as portable as it is today.
>
> But would be much faster! Take a look here:
>
No, it would not. Yes, GPUs are fast at some things, but they are slow
at others. Certain techniques work well when moved to the GPU. POV-Ray
uses several that do not fall into that category.
Now, lets say we just move some parts to the graphics card, starting
from the 3.6 code that is stable right now. That would involve not just
updating the code to be highly parallel, but updating how certain
interactions are handled. That parallel part is currently being tested
in 3.7. And as andrel said, once you start handling each different
object type in a different manner, things get complicated.
First off, it is not likely that the parser will be moved to the
graphics card, just not something that I see moving that direction. The
most obvious thing, to me anyways, would be the ray intersection test.
Now, in doing that, you have lost some precision on some platforms but
not others, due to different graphics cards supporting different float
sizes. Ta-da, instant bug reports.
Lets say we get around those bugs, by some how enforcing the size of
double float. Compared to certain cards then, even with multiple cores
in parallel, the CPU's FPU is faster. No gain. But, lets say that it is
enforced to only compile on cards that support double precision floats.
This is something the GPU excels at, so it should offer some obvious
speed increases, as long as everything works. The difference is, that
what the graphics card is really good at is taking vector math like that
and outputting the results to the VGA or DVI or HDMI cable. And what we
probably would need is for that data to go back across the bus and to
the CPU.
My GPU coding skills are lacking, and I haven't read the POV-Ray source
in ages, so I am probably wrong on this. My suspicion is that the
texture code is still going to be handled on the CPU. Too many possible
things to stack up, but what this means is that all of those
intersection tests are going to get dumped back to the CPU. Now, another
decision: do you keep the GPU testing rays that may spawn from those
intersections, without knowing which ray you want? If the texture*
supports bumps, then tracing the reflection from an intersection is
probably a waste of a test. So would be tracing everything else that ray
eventually intersects, and all of it's children and so on. So, now you
have to clutter the pipe again by sending all of your requests for ray
tests over to the GPU.
*if the object is deformed by the bumps, and the geometry reflects that,
then tracing the ray is a good option.
This would be a great thing to benchmark; to see how much render time is
spent on the ray intersection tests, and how much data is moved around
in processing all of them. If the amount of data is small enough, and if
the tests would be sped up appreciably*, and if the geometry can all be
loaded into the graphics card beforehand, then it may be worth the time
investment to move that code to the GPU.
*it may happen that the data is small enough, and the tests are sped up,
but the overhead for having to process all of this information outside
the CPU outweighs the benefits.
But not during the move from 3.6 to 3.7 as there are too many other
things being moved and changed.
> Can you imagine what povray could do comparatively without getting
> boiled down by unbiased techniques?!
>
Those unbiased techniques are what allows them to appear so fast. The
video appears to be getting 10fps tops, and between 2 and 4 the rest of
the time. Yes, unbiased rendering is slower to achieve the same image as
a biased renderer, however you can stop it much sooner and get a full
resolution picture. That picture just has more noise.
Your question comes out as if you were asking "Could you imagine what
povray could do by using unbiased techniques for single sample speed
increases without being unbiased?" I think the quickest answer would be
"Not really, but set the max depth to 1 and lets see what the pictures
look like."
Post a reply to this message
|
|
|
|
Amazing the amount of self-denial one has to go in order to cope with excuses
for why his favorite rendering engine should not evolve.
Sabrina Kilian <ski### [at] vt edu> wrote:
> > Can you imagine what povray could do comparatively without getting
> > boiled down by unbiased techniques?!
> >
>
> Those unbiased techniques are what allows them to appear so fast. The
> video appears to be getting 10fps tops, and between 2 and 4 the rest of
> the time. Yes, unbiased rendering is slower to achieve the same image as
> a biased renderer, however you can stop it much sooner and get a full
> resolution picture. That picture just has more noise.
>
> Your question comes out as if you were asking "Could you imagine what
> povray could do by using unbiased techniques for single sample speed
> increases without being unbiased?" I think the quickest answer would be
> "Not really, but set the max depth to 1 and lets see what the pictures
> look like."
No, my question is merely like: "hey, I can render scenes in povray in seconds
rather than dozens of minutes. And truly complex ones in a few hours rather
than days."
I'm not impressed with that demo's noisy 4fps display. I'm impressed to see
scenes with full light transport phenomena set that usually take 1 hour to
denoise being noise-free in a couple of minutes.
This is the future: tapping all that hidden power that was being ignored so far
because we insist on using a lame-O chip geared at word processing to do math
operations.
Post a reply to this message
|
|
