gpgpu?

[meosoft]

Hi,

I'm sure this is not any original idea, but I want to ask if there are any possibilities of using this in your renderer. I know that it isnt anything easy or strightforward but what if a libary was created independently from the core (that would remain CPU-based) and then used e.g. like a plugin? That way the users who do not own the newest (GPU) hardware wouldnt have to wory, and yet those who have e.g. NV8600 could get an inmense power boost (according to the GPGPU presentation on Siggraph 2007, GPUs have around 55GFLOPS compared to Core2 Duo 2GFLOPS). The architecture is ideal since it is developed for graphics and could be very well used in this project, since there are many processors (320 or so) that could do the same thing - calculate samples

Although I am good with PHP, I have written ony some small programs in C/C++ to the date so I am not the best candidate to write this. And I also I dont have any og those NV8xxx or ATi2xxx HW - only NV7600GT.
So please, anyone, think about this and I am willing to help any way I can because I really like this project (GNU unbiased renderer - no more indigo troubles on linux)

P.S.
I understand this is maybe not the right time to start with this advanced stuff since you have just started this wonderful project and there is not even a stable codebase but maybe this could be an idea for the future releases

Thanks for your attention

[zcott]

I'd like to see that happen too. GPGPUs have a great potential for speeding up rendering, which as we all know can take quite a while in unbiased engines. Modern GPUs are basically parallel vector processors and pathtracing algorithms parallelize nicely... Harnessing that power would certainly be a huge step forward!

I do think however, that it's important to first focus on providing a stable and full-featured version of Lux before we start forking off into more advanced stuff like this. I'll be looking into it though.

[Radiance]

i've done some experiments in the past with cuda on a G80 (nvidia 8800gtx)

altough it's sureley possible, one of the issues is that gpu's don't have much fast memory (like CPU's have an L2/L3 cache).

as such they are only suitable for algorithms with no or tiny stacks.

ray intersections, the biggest waste of time in a raytracer requires a different approach on GPUs and new algorithms are starting to emerge (stackless kd-restart for example.)

hopefully soon more development in this area will make more options easily available.

greetz,
radiance

[droid]

altough it's sureley possible, one of the issues is that gpu's don't have much fast memory

You've hit the nail on the head there. The big problem will always be that, no matter how you chop things
up, all the scene data needs to be resident in ultra-fast memory. Near-future PCs are going to routinely ship
with >16Gb of mega-cached RAM and we'll all be able to enjoy rendering mega-million-poly scenes, but
not on GPUs until they also ship with the same amounts.

Ian.

[Radiance]

i also think that it would be a waste of time currently.

why ?

because the current SDK's (like CUDA, etc...) are very young and not very GENERIC at all...

it would require major changes to the code.
they only support C (no C++), and have various restrictions.
they also require specific code and structure to copy memory back and forth between RAM and video RAM.

i'm sure 1-2 years from now more compatible layers will emerge which will allow for compilation of relativeley unmodified C++ code for execution on the CPU and GPU. (one big virtual CPU with lots of threads)

greetz,
radiance

[KnaxKnarke]

because the current SDK's (like CUDA, etc...) are very young and not very GENERIC at all...

Another problem is, that you have to support different SDKs to reach the masses. Classic GPGPU with GLSL/Cg/HLSL for older cards
with SM3 (I think SM2 is of no real use for GPGPU: no floats, no loops, no branching...) or something like Sh/RapidMind

For the new generation GPUs there are CUDA for NV and CTM for AMD. So no common platform anymore (ok, SM3 and the shader compilers
are so different, that writing shaders for both big GPU brands was hardly useful)

So a lot work for a fast moving target. The SM4-gen is only fast, if you have the bigger models. Forget every NV card without an
G80 for CUDA! Not enough power, not enough VRAM.

i'm sure 1-2 years from now more compatible layers will emerge which will allow for compilation of relativeley unmodified C++ code for execution on the CPU and GPU. (one big virtual CPU with lots of threads)

I also hope so. The steps from GLSL/SM3 to CUDA was a big one. Hopes for G9x and CUDA 1.x are high. A pity that double precision is dropped for the
consumer cards. You have to buy Quadro or Tesla to get it. I think two Intel Xeon Quadcores are cheaper and of more use for shooting rays...

There were interesting papers about CUDA ray tracing at EG and RT07 from the Saarbrücken guys around Slussalek:
EG: http://graphics.cs.uni-sb.de/Publications/2007/StacklessGPURT.pdf
RT07: http://graphics.cs.uni-sb.de/Publications/2007/BVHonGPU.pdf

One stackless and one with a stack for ray bundles in the shared mem. AFAIR they managed the bundle traversal at warp level
to avoid syncthreads. Sounds cooler than kd-restart or ropes...

And with BVH it can handle the powerplant with 12 million triangles. Also with a Quadro FX 5600 and 1.5 GB VRAM you can also
use kd trees for big models on GPU.

But for now, GPU ray tracing is still difficult and maybe not worth the effort. CUDA is still buggy, I wonder when NV manages to get
it into games for physics (or at least include it into the standard forceware package). Now that Havok belongs to Intel, the NV claims
about G8x to provide physics on the GPU is no marketing announcement anymore, it's simply a lie to the customers.

But the talk of real time ray tracing of games from Intel is even a bigger lie. Or do they want to sell x86-clusters to hardcore gamers

[zcott]

Another problem is, that you have to support different SDKs to reach the masses. Classic GPGPU with GLSL/Cg/HLSL for older cards with SM3 (I think SM2 is of no real use for GPGPU: no floats, no loops, no branching...) or something like Sh/RapidMind

Yeah, the inconveniently-named Sh was a very interesting approach. Too bad they went commercial...

There were interesting papers about CUDA ray tracing at EG and RT07 from the Saarbrücken guys around Slussalek:
EG: http://graphics.cs.uni-sb.de/Publications/2007/StacklessGPURT.pdf
RT07: http://graphics.cs.uni-sb.de/Publications/2007/BVHonGPU.pdf

Nice papers, thanks.

And with BVH it can handle the powerplant with 12 million triangles. Also with a Quadro FX 5600 and 1.5 GB VRAM you can also use kd trees for big models on GPU.

But for now, GPU ray tracing is still difficult and maybe not worth the effort.

If they manage to get near-realtime RT I'm sure it could be used to offload some work from the cpu for our not-so-realtime needs. The question of whether it's worthwhile with the current APIs still remains though...

[anderslanglands]

It'll be interesting to see where this goes. In a few years we'll have massively multicore x86 CPUs from intel and amd which should be much more applicable for our needs anyway. The realtime raytracing community's already doing some pretty amazing stuff on current architectures so my gut tells me that's the way forward. By its very nature raytracing needs to be completely general and able to support massive datasets. Mapping it to the GPU just requires jumping through too many hoops at the moment.

[Lord Crc]

Wild idea here, probably not original: Offloading the post-tracing code to the GPU. Ie shading/texturing. Would be a bit like deferred rendering, except the CPU fills the g-buffer, and the GPU then does the shading.

Easiest way I can think of right now to use the GPU right now.

[anderslanglands]

That assumes that a) your shading code can be easily representable on the GPU, b) that shading is a large expense in your render (compared to the cost of shooting rays), and c) your shading points are coherent enough to take advantage of the stream processors, none of which are true. It's a shame but being able to leverage the GPU in an efficient, general fashion takes a huge amount of work at the moment.