![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
keep diluting/lying yourself, you're doing a great job, keep it up!
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Mon, 17 Aug 2009 09:27:31 -0700, Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Mon, 17 Aug 2009 17:50:30 +0100, Stephen wrote:
> On Mon, 17 Aug 2009 09:27:31 -0700, Darren New <dne### [at] san rr com> 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.
LOL
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Mon, 17 Aug 2009 10:41:17 -0700, Darren New <dne### [at] san rr com> wrote:
>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.
Sorry, I thought that you were stoking the fire.
--
Regards
Stephen
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |