CPU (real time) raytracing references and articles?

(L) [2015/05/26] [tby mrluzeiro] [CPU (real time) raytracing references and articles?] Wayback!

Hello all,
It seems that realtime raytracing on CPUs is fading away because of the advance of GPUs, still.. does anyone know a good reference with examples / materials / etc for RTRT on CPUs ?

(L) [2015/05/27] [tby szellmann] [CPU (real time) raytracing references and articles?] Wayback!

I do not agree that GPU ray tracing can (in general) outperform the CPU by orders of magnitude. At least not, if the scene geometry doesn't entirely fit into the caches of the GPU's streaming multiprocessors.
With Visionaray ([LINK https://github.com/szellmann/visionaray]) you can run the same C++ ray tracing code, compiled into x86 SIMD code (so far only packets), and into CUDA code. We did (informal) tests with highly coherent workloads (primary rays) and also with highly incoherent workloads (unoptimized path tracing). Visionaray uses an sBVH (regardless of the algorithm, we're working on QBVHs) with while-while traversal.
Actually, when testing on our dual socket 16 core Xeon E5-2680, we see similar frame rates compared to the same implementation running on a GTX Titan. I mean, the machine's L3 data cache has a similar capacity as my first PC's hard drive had [SMILEY :)] So in my opinion we should not generally rule out CPU ray tracing!
Best,
Stefan

(L) [2015/05/28] [tby Dade] [CPU (real time) raytracing references and articles?] Wayback!

>> szellmann wrote:Actually, when testing on our dual socket 16 core Xeon E5-2680, we see similar frame rates compared to the same implementation running on a GTX Titan.
Well, I guess a dual socket 16 core Xeon E5-2680 is far more expansive than a single GTX Titan (even including the price of some kind of host CPU). You can install up 16 GPUs in a single PC thanks to PCIe extenders. Achieving the same level of performance with CPUs requires far more money (and space).
In my experience, you have to rule out GPU rendering when you are hitting some hardware limit (i.e. ram, I/O, etc.) or re-writing/porting existing software is too expansive otherwise CPU rendering, in term of brute performance and price, isn't so competitive.
At the end of the day is about using the right tool (GPU or CPU) for your job, as usual.

(L) [2015/05/28] [tby szellmann] [CPU (real time) raytracing references and articles?] Wayback!

>> Well, I guess a dual socket 16 core Xeon E5-2680 is far more expansive than a single GTX Titan (even including the price of some kind of host CPU).
Right, and to be fair one would actually have to compare with two Titans. It's only that I cannot confirm the 10x plus speedups you see on some GPU vendors' marketing slides. Only with tiny scenes, then the speedup is impressive, even if the workload is incoherent.
>> At the end of the day is about using the right tool (GPU or CPU) for your job, as usual.
That's my opinion, too.

(L) [2015/05/31] [tby atlas] [CPU (real time) raytracing references and articles?] Wayback!

It's all too easy to get dissuaded from the CPU when you look at recent research results, but everybody measures MRays/s differently (some to a curious degree). I think what happened is that researchers (in all compute fields) flocked to the GPU for its relatively effortless parallelism and the associated influx of results, meanwhile under-researching the exploitation of modern CPU architecture. It's very difficult to properly handle your threading/SIMD/ILP/pipelining/latency-hiding/cache-awareness/etc. on modern CPUs, but I think if these things are accounted for, you tend to see the pendulum will swing back the other way; especially with MIC host chips with AVX-512 (eventually 1024?) around the corner.
Just flip a coin [SMILEY :)]

(L) [2015/06/03] [tby mrluzeiro] [CPU (real time) raytracing references and articles?] Wayback!

>> atlas wrote:I think what happened is that researchers (in all compute fields) flocked to the GPU for its relatively effortless parallelism and the associated influx of results, meanwhile under-researching the exploitation of modern CPU architecture.
That's precisely what I meant by "fading away", the researchers are now following the hype of the new GPU capabilities, so not much news on CPU research..

(L) [2015/06/03] [tby atlas] [CPU (real time) raytracing references and articles?] Wayback!

Right, well as far as CPU papers go I like "dynamic ray stream traversal" for capturing hidden ray coherence without compromising independent path orders (as with packet traversal), and using single ray traversal when coherence is lost. They also have code available with a few smart optimizations. It outperformed the latest Embree when I implemented it

(L) [2015/06/10] [tby ziu] [CPU (real time) raytracing references and articles?] Wayback!

You can just look at the FLOPS on both kinds of hardware and extrapolate from that. The GPU is never going to be 'orders of magnitude' faster.
I have tried running OpenCL code tweaked to both CPU and GPU platforms. I found the performance differences are relative to the difference in peak GFLOPS in both platforms that I discussed above.
The main advantages of using the CPU right now are that it is a lot simpler to code for and debug (yay! memory protection!) and that it has virtual memory support. So can you can render these gigantic datasets effortlessly on a CPU which would be quite cumbersome to do on a GPU.
However both of these features are supposedly going to arrive to GPUs somewhere in the next two generations. So this situation is likely to change in the GPUs favour.
The advantage of using something like CUDA or OpenCL cannot be underestimated either. The programming model for those languages is a lot simpler when you are writing this kind of many-threaded code than bothering with Intel's many vector extensions that keep changing all the time.

CPU (real time) raytracing references and articles? back

Board: Home Board index Raytracing General Development