|
![](/i/fill.gif) |
Orchid XP v8 wrote:
>>> If your work packages are large enough, then these are no issues. But
>>> in a raytracer, be prepared for rather small work packages.
>>
>> And that's another problem. While a GPU has *hundreds* of cores that
>> all work in parallel, in raytracing you're unlikely to encounter more
>> than a few dozen rays which require the same test. It's just not
>> efficient to solve this problem with GPUs.
>
> I'm not sure I agree with these statements.
>
> Tracing a scene involves shooting thousands, or even tens of thousands
> of rays at the top-level geometry. While there may be some objects which
> are quite small, most objects will be hit by hundreds and hundreds of rays.
Let's say a scene rendered for display on a 1080p TV has approximately
300 objects in it, each one covering a similar portion of the display
(for simplicity's sake).
That's a total of 1,920x1,080=2,073,600 pixels, or 6,912 for each
object. Admittedly, this is more than my statement of "a few dozen" :)
However, each level of recursion will split the groups rays - let's
say into 4 groups (I honestly think they would be grouped in more,
smaller, groups, but this will make the math easier). After only 4
levels of recursion (a value entirely common in scenes) the rays are
bundled in groups of 25 (assuming an even distribution, of course).
With a smaller image, more objects, and less tight grouping, you'd get
such small groups after only one or two levels of recursion.
> More to the point, if a GPU was more like a CPU, it wouldn't be faster
> than a CPU.
True ;)
...Chambers
Post a reply to this message
|
![](/i/fill.gif) |