 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 1) Recursion. As clipka (Christian?) wrote, it is absolutely essential
> for POV.
>
> 2) Data parallelization versus code parallelization (this is related to
> the first, but is not strictly the same).
>
> The ray tracing algorithm follows drastically different code branches on a
> single set of data, based on recursion (reflections & refractions), as
> well as the other various computations needed (texture calculation, light
> source occlusion, etc) which almost all need access to the entire scene.
Often you need to drastically change your algorithm to get it running well
on a GPU. It's quite trivial to rewrite the raytracing algorithm to work on
masses of rays in parallel with no branching or ray spawning, and then do
the branching/spawning for the rays all in one go. After this you can
efficiently use the GPU and CPU in parallel.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The solution in both cases is to put rays into "queues", such that all the
> rays in a given queue take the same code path [for a while]. When you need
> to spawn a secondary ray, you add it to a queue rather than recursively
> tracing it. When some rays hit an object and others don't, you add them to
> different queues.
Why add it to a different queue? All rays that still need to be traced
(whether they are reflection, refraction, primary or shadow rays) simply
need to be intersected with the scene geometry. If you like you could keep
a flag in the queue for each ray to say what type it is, but the GPU part
that does the ray-scene intersection probably doesn't care what sort of ray
it is.
In that way the GPU will just process as many rays as it can in batches
until the scene is complete. The CPU would handle preparing the queue at
each step, ie removing rays that have terminated and inserting new rays for
shadows and reflections etc.
Of course to be able to do efficient scene intersection on the GPU it would
probably be best to only allow triangle-based scenes, and figure out some
way to store a Kd-tree of triangles efficiently in a texture. Sounds like
the sort of thing someone has already done a PhD on :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> When some rays hit an object and others don't,
>> you add them to different queues.
>
> Why add it to a different queue? All rays that still need to be traced
> (whether they are reflection, refraction, primary or shadow rays) simply
> need to be intersected with the scene geometry.
I was thinking more along the lines of each surface possibly having a
different code path for computing illumination. Rays in the same bundle
can't take different code paths.
> In that way the GPU will just process as many rays as it can in batches
> until the scene is complete. The CPU would handle preparing the queue
> at each step, ie removing rays that have terminated and inserting new
> rays for shadows and reflections etc.
Depends on whether you're thinking of running the whole computation on
the GPU, or just the ray intersection tests, or what.
> Of course to be able to do efficient scene intersection on the GPU it
> would probably be best to only allow triangle-based scenes
I see no especial reason why you can't do arbitrary intersection tests
on a GPU. The math isn't that complicated. The only real problem is
going to be trying to run something like isosurfaces, which use adaptive
space division; a GPU probably won't like that. But something like a
Newton iteration should be fine. [That obviously isn't applicable to
general isosurfaces though...]
> and figure
> out some way to store a Kd-tree of triangles efficiently in a texture.
Also depends on whether you're trying to write your code as a shaper, or
use a real GPGPU system. (Such as the OpenCL in the title.)
> Sounds like the sort of thing someone has already done a PhD on :-)
Indeed, that's where I read about the render queue approach. (No, I
don't remember where *exactly*.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I was thinking more along the lines of each surface possibly having a
> different code path for computing illumination. Rays in the same bundle
> can't take different code paths.
Sure they can, you just have an "if" in the shader code based on some flag
in the ray data.
> Depends on whether you're thinking of running the whole computation on the
> GPU, or just the ray intersection tests, or what.
Some things I think the CPU still needs to do, like preparing the ray data
to put on the GPU at each step. It is quite hard to write a shader that does
anything other than return one "output value" per "pixel", ie you can't
write a shader that returns a veriable number of rays, the only thing you
can do is return a flag set that means "spawn another ray".
> I see no especial reason why you can't do arbitrary intersection tests on
> a GPU. The math isn't that complicated.
I was thinking more about how to store the scene on the GPU efficiently, if
you just have a triangle list it is relatively simple.
> The only real problem is going to be trying to run something like
> isosurfaces, which use adaptive space division; a GPU probably won't like
> that.
Nah it's no problem :-) Modern GPUs don't have any limit on loops or number
of instructions or anything like that.
> Also depends on whether you're trying to write your code as a shaper, or
> use a real GPGPU system. (Such as the OpenCL in the title.)
I think something like a raytracer will be too complicated for a computer to
try and figure out how to put it on the GPU the best way, needs to be hand
coded by an intelligent person :-)
> Indeed, that's where I read about the render queue approach. (No, I don't
> remember where *exactly*.)
Damn. If you think up *anything* you think is new, you can be guaranteed
that someone else somewhere has already thought of it :-) The internet just
makes it easy to find that person!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I was thinking more along the lines of each surface possibly having a
>> different code path for computing illumination. Rays in the same
>> bundle can't take different code paths.
>
> Sure they can, you just have an "if" in the shader code based on some
> flag in the ray data.
I was under the impression that all cores in the bunch would have to
take the same branch of the if - you can't have half go one way and half
go the other. (That's what makes it a SIMD architecture.)
I was also under the impression you can have predicated instructions,
however. (I.e., a single instruction that executes or doesn't based on a
condition. But not a whole alternate execution path.)
> Some things I think the CPU still needs to do, like preparing the ray
> data to put on the GPU at each step. It is quite hard to write a shader
> that does anything other than return one "output value" per "pixel", ie
> you can't write a shader that returns a veriable number of rays, the
> only thing you can do is return a flag set that means "spawn another ray".
> I was thinking more about how to store the scene on the GPU efficiently,
> if you just have a triangle list it is relatively simple.
Again, depends on whether you're writing a shader, or using a GPGPU system.
>> The only real problem is going to be trying to run something like
>> isosurfaces, which use adaptive space division; a GPU probably won't
>> like that.
>
> Nah it's no problem :-) Modern GPUs don't have any limit on loops or
> number of instructions or anything like that.
But they don't allow recursion. That's the issue.
>> Also depends on whether you're trying to write your code as a shaper,
>> or use a real GPGPU system. (Such as the OpenCL in the title.)
>
> I think something like a raytracer will be too complicated for a
> computer to try and figure out how to put it on the GPU the best way,
> needs to be hand coded by an intelligent person :-)
...and?
All GPGPU does is allow you to run programs on a GPU which don't
necessarily have to be shaped like shaders. You still have to write the
code yourself. It's just that you don't have to pretend it's
graphics-related even if it isn't.
> Damn. If you think up *anything* you think is new, you can be
> guaranteed that someone else somewhere has already thought of it :-)
> The internet just makes it easy to find that person!
I've had the same problem with mathematics my entire life.
Do you know how hard it is to draw a cube made of 8 cubes and measure
all their sides? Do you know how long it takes to expand (x+y)^9
manually, by hand? Do you have any idea how long it takes to figure out
what the pattern is and where it's coming from?
...and then I discover some entry-level textbook that tells me how some
dead guy already figured all this out several centuries ago. AND FOR
ARBITRARY EXPONENTS!! >_<
Why do I bother?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
keep diluting/lying yourself, you're doing a great job, keep it up!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers wrote:
> Saul Luizaga wrote:
>>> No, you didn't even ask a question.
>>
>> news://news.povray.org:119/4a850da7@news.povray.org, check the last
>> paragraph, proves you wrong. Did you liked to be corrected?
>
> Yes, I do as a matter of fact. I don't like being wrong.
>
> ....Chambers
yeah, right.... hahaha
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Saul Luizaga wrote:
> keep diluting/lying yourself, you're doing a great job, keep it up!
That would be "deluding", not "diluting". :-)
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 17 Aug 2009 09:27:31 -0700, Darren New <dne### [at] san rrcom> wrote:
>Saul Luizaga wrote:
>> keep diluting/lying yourself, you're doing a great job, keep it up!
>
>That would be "deluding", not "diluting". :-)
Like it makes any difference? Just show him where the fluoride lake is.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen wrote:
>> That would be "deluding", not "diluting". :-)
> Like it makes any difference?
Most speakers of english-as-a-second-language around here seem to appreciate
learning the right words, is all.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
