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] sanrrcom> 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

On Mon, 17 Aug 2009 17:50:30 +0100, Stephen wrote:

> On Mon, 17 Aug 2009 09:27:31 -0700, Darren New <dne### [at] sanrrcom> 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

On Mon, 17 Aug 2009 10:41:17 -0700, Darren New <dne### [at] sanrrcom> 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