FYI: Open source renderer that claims to be 11 to 30 times faster than Cycles on a GPU.
4 Likes
OK that might be great, but how come there isn’t even a Cycles rendered image?
Is this weird considering it’s opensource like PBRT at Mitsuba?..
1 Like
So I actually have an opinion here (and for fair disclosure this is my own opinion, not related to employer). Saw this when it came out at SIGGRAPH asia and it is cool, but focusing on the speed is the wrong point IMO.
What’s really cool here is the Domain Language that allows easily writing GPU code that is FAST. Normally to write a CUDA or OpenCL / HIP whatever renderer there is a steep leaning curve. Something like this Luisa language allow writing a renderer or similar application without getting into the steep nitty gritty of something like CUDA. The renderer they wrote I think is more of a proof of concept for the language. It’s not fully featured like Cycles but probably was written in a fraction of the developer time.
I played around with a similar concept with a language called “Taichi”. Which is similar but more focused on python as a basis for the language. Looks like Luisa has a python front end as well, but I haven’t tried it yet. At least with Taichi I was able to really quickly (like a day) GitHub - bsavery/BlenderPythonRenderer: A Python GPU renderer for Blender using the Taichi package write a python GPU path tracer and make it work with Blender. Pretty cool!
Again IMO but I think this is the future. You have Metal, HIP, CUDA, OneAPI. Having a higher level abstraction and easier to write language like this that allows writing a renderer and be cross platform is awesome. Again I think their renderer is meant to be a benchmark / proof of concept but certainly shows the promise of the language.
20 Likes
As one of the authors, thank you for focusing on the point of this paper. We spent a lot of words explaining the motivation behind DSL and abstractions for runtime. In fact, we must admit that by writing high-level runtime api and advanced DSL, we will never reach 100% performance of the native backend, but that is not what we want, what we need is to find a balance between development efficiency and performance. We have the ambition to support multiple front-end languages (C++, Rust, Python, …)that can be mixed together and can be used in a wide range of areas such as film and video rendering, game-engines, DCC, etc., so that developers don’t have to worry about optimizing the underlying hardware.
17 Likes
Is something similar to SYCL?
1 Like
We have a discord server here:
Is there any compiled version for windows to try out, please?
1 Like