GPU accelerated path tracing


#1

I just found an interesting blog about different algorithms for GPU path tracing.

Ray Tracey’s blog

Also the author of this blog (Sam Lapere) have some shared code on GitHub

I’m posting here hoping that will be helpful if somebody want to add some GPU capabilities for Appleseed.


#2

Thanks!

If we were to implement GPU rendering, we might use the NVIDIA Optix ray tracing library instead of reimplementing our own ray tracing code.

That said, we don’t have any immediate plans to pursue GPU rendering.


#3

I was big on GPU rendering until I got an (oldish) Xeon powered workstation with enough memory to handle the scenes I was working on. The 6Gb 1060 was starting to squeak a bit and while the Xeon isn’t AS fast, it’s impressively not that much slower. To be fair, it did cost a lot more but you have to balance that against a dedicated video card vs. a whole professional quality workstation.

With so many companies like Facebook dumping their own Xeons on the market for next to nothing, these systems are becoming a real alternative to i7 + a 1080 Ti single system. Building a small render farm (32, 64 or more physical cores) using headless rack servers is no longer out of reach for serious small studios and dedicated SOHO users. That will smoke a dedicated CUDA box in performance and handle much, much larger scenes.

Plus, you’re not limited to whatever we can do with CUDA acceleration. I’m really impressed with the latest iteration of Appleseed - so much so that I’m seriously considering doing some documentation as that’s really my area of expertise these days.


#4

Thanks for the kind words @marcdraco! We would be grateful for any help regarding documentation. Make sure to get in touch with us to make sure we avoid duplicate efforts.

Regarding GPU rendering:

While appleseed is first and foremost a CPU-based renderer, we did start an effort recently (currently dubbed “appleseedX”) to investigate how GPU rendering would work in appleseed. It’s in very early stages at the moment but with the advent of dedicated raytracing hardware in NVIDIA’s RTX cards (and presumably soon in AMD cards as well), it feels like the right time.


#5

Of course, duplication is never a good idea. That’s just wasted effort.

Do you have a centralized hub where the documentation writers are hanging out? The first thing I noticed coming in from the cold and a non-technical background where modern ray-tracing is concerned, is the lack of detail regarding artistic vs. physical options.

Coming in as an artist (cough, splutter) it would help to know what starting settings are suitable for CG animation work to be composited into live action vs. (say) a static render. I’m happy to rummage through these myself but when I understand it, I can explain it to others simpler terms.

A real time-saver I chanced on in the existing documentation was the sampling passes vs. samples taken. I think the example was switch from one pass, 64 samples to eight passes of eight samples each. Same overall quality (64 samples) but the basic image renders more quickly so you can see where likely trouble spots are rather than having to wait for something that might be lurking in one of the last few tiles! :wink:


#6

Do you have a centralized hub where the documentation writers are hanging out?

Yes, that would be the #docs channel on our Discord server (you can join with this link).

Hehe… Many such tricks exist, but without documentation users are unlikely to discover them…

Documentation-wise, here is what we have right now:

Our long term goal is to move appleseed docs to https://appleseed.readthedocs.io/en/latest/ (which is currently empty) and to move the custom OSL shader docs to its own place, and then to link everything properly.

@luis is the hero who wrote most of our docs and who set things up on readthedocs.org. You may want to talk to him.