CPU (real time) raytracing references and articles?

Practical and theoretical implementation discussion.
Post Reply
mrluzeiro
Posts: 28
Joined: Tue May 26, 2015 2:27 pm

CPU (real time) raytracing references and articles?

Post by mrluzeiro » Tue May 26, 2015 3:03 pm

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 ?

AranHase
Posts: 9
Joined: Fri May 16, 2014 11:00 pm

Re: CPU (real time) raytracing references and articles?

Post by AranHase » Tue May 26, 2015 5:49 pm

CPU raytracing looks quite strong with Embree:

https://embree.github.io/

szellmann
Posts: 51
Joined: Fri Oct 10, 2014 9:15 am
Contact:

Re: CPU (real time) raytracing references and articles?

Post by szellmann » Wed May 27, 2015 1:52 pm

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 (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 :) So in my opinion we should not generally rule out CPU ray tracing!

Best,
Stefan

Dade
Posts: 206
Joined: Fri Dec 02, 2011 8:00 am

Re: CPU (real time) raytracing references and articles?

Post by Dade » Thu May 28, 2015 7:57 am

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.

szellmann
Posts: 51
Joined: Fri Oct 10, 2014 9:15 am
Contact:

Re: CPU (real time) raytracing references and articles?

Post by szellmann » Thu May 28, 2015 8:56 am

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.

atlas
Posts: 26
Joined: Thu Apr 16, 2015 12:01 am

Re: CPU (real time) raytracing references and articles?

Post by atlas » Sun May 31, 2015 1:15 am

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 :)

mrluzeiro
Posts: 28
Joined: Tue May 26, 2015 2:27 pm

Re: CPU (real time) raytracing references and articles?

Post by mrluzeiro » Wed Jun 03, 2015 12:19 pm

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..

atlas
Posts: 26
Joined: Thu Apr 16, 2015 12:01 am

Re: CPU (real time) raytracing references and articles?

Post by atlas » Wed Jun 03, 2015 9:37 pm

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

ziu
Posts: 29
Joined: Sat Aug 17, 2013 8:46 pm

Re: CPU (real time) raytracing references and articles?

Post by ziu » Wed Jun 10, 2015 9:20 pm

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.

Post Reply