Writing a Portable CPU/GPU Ray Tracer in C#

Writing a Portable CPU/GPU Ray Tracer in C#(mellinoe.github.io)

116 points by mellinoe 8 years ago | 22 comments

IvanK_net 8 years ago |

I made a real-time ray-traced game a few years ago, that works in a browser :) You can increase the resolution, while FPS drops. http://powerstones.ivank.net

Const-me 8 years ago |

> You give it regular C# structures and methods, and it automatically converts them to HLSL, GLSL SPIR-V, and Metal shaders.

Code introspection is one of the huge strengths of .NET ecosystem.

You can even do it multiple levels of abstraction: bytecode (using e.g. Mono.Cecil), with built-in reflection API, with built-in expressions API since .NET 3.5, and apparently this project uses even higher-level approach, Roslyn.

I have never transformed C# code into shaders, when I’m working on something similar I usually prefer traditional GPU languages like HLSL or CUDA, because tooling (e.g. visual studio can debug both).

I transformed expressions into NoSQL database queries, worked well. Here’s the main parts: https://github.com/Const-me/EsentSerialize/blob/master/Core/...

seanmcdirmid 8 years ago | |

You can also roll your own expression language using operator overloading and then plug that into the DLR or HSL, or whatever as needed (I did this in https://archive.codeplex.com/?p=bling). It doesn’t allow for statements, however, which introspection gives you.

It is much harder in the new UWP, however, where dynamic features (reflection, introspection, native JIT via the DLR) are no longer guaranteed to be present.

zamalek 8 years ago | | |

Don't forget that Linq operates over duck-typed extension methods, so you can also define your own wizardry there.

pjmlp 8 years ago | |

While it is great feature that I enjoy a lot, it isn't the only eco-system with it. :)

dahart 8 years ago |

Great write-up! Your speedups look like they line up as expected. Would you happen to know why Aras's look a bit weird, is it the devices he's using? I'm referring to his Metal timings being more than 10x slower than D3D, and being almost comparable to C++.

> One of my goals was “use as much of the same code as possible on the CPU and GPU”.

Great idea, it's hard to debug GPU code, and super convenient to have something that you can run & debug on the CPU, then just flip a switch and get GPU speedups!

> Another obvious limitation is that GPU code cannot recurse.

Yep. I bet this changes relatively soon, since you can sometimes use recursion in OpenCL & CUDA.

It's a fun exercise in ShaderToy to write a recursive ray tracer. Here's mine: https://www.shadertoy.com/view/XllBRf

And here's a much better one: https://www.shadertoy.com/view/4scfz4

mellinoe 8 years ago | |

> Great write-up! Your speedups look like they line up as expected. Would you happen to know why Aras's look a bit weird, is it the devices he's using? I'm referring to his Metal timings being more than 10x slower than D3D, and being almost comparable to C++.

Thanks for reading! Since Aras is using a GTX 1080 TI on Windows, and an Intel Iris Pro on Mac, I think the numbers make sense. In my case, my GTX 770 is pretty old, and my 2017 MacBook is pretty new, so the numbers line up better.

> It's a fun exercise in ShaderToy to write a recursive ray tracer. Here's mine: https://www.shadertoy.com/view/XllBRf

> And here's a much better one: https://www.shadertoy.com/view/4scfz4

Nice! I should add accumulation to mine -- it'd look much better for barely any effort.

aras_p 8 years ago | |

> I'm referring to his Metal timings being more than 10x slower than D3D

In my case it's the difference in hardware. DX11 results are on GTX 1080 Ti, whereas Mac are on Iris Pro on 2013 MacBookPro. > 10x performance difference between these GPUs is entirely expected.

dahart 8 years ago | | |

Totally makes sense; thanks for the explanation!

ohf 8 years ago | |

> Yep. I bet this changes relatively soon, since you can sometimes use recursion in OpenCL & CUDA.

Am I correct in assuming you can only recurse when the recursion can be "unrolled" into a simple loop? In other words, no program flow structures.

dahart 8 years ago | | |

You can do real recursion sometimes, and real program flow. It does depend on CUDA version & chipset, but most modern ones support flow control. (https://stackoverflow.com/questions/3644809/does-cuda-suppor...)

I think there are still cases where it won’t work right due to other libraries that might be involved, I’ve had recursion fail even on a new GPU with cuda 9.

Even if you can use recursion, it’s not usually a good idea since you’ll run into thread divergence problems.

wolfspider 8 years ago |

Always love your work! Going to check this one out right away. Yeah GLES and readpixel aren’t friends like for instance GPUImage uses the hardware backbuffer to store it as a workaround: https://stackoverflow.com/questions/12813442/cvopenglestextu...

So it’s device specific to implement the same thing I believe GPUImage uses a stub for this to apply the same shaders you have in mind.

pjmlp 8 years ago |

Very interesting reading, we need more article about alternative approaches.

ionafgnio 8 years ago |

Is there a legitimate reason for D3D12 to exist? It seems like just a locked-down version of Vulkan to me intended to kill cross-platform gaming (textbook Microsoft Embrace, Extend, Extinguish). I haven't heard of any advantages in performance or ease of development. But I'm certainly no expert.

Unrelated note: there's something really funky going with the comparison between the desktop and the laptop. The desktop is pretty high-end and should just obliterate that Macbook. It's seriously weird that they're so close. I'm not sure I trust the results.