Amazing project! Just a few questions...

[boberfly]

This is an amazing project thank you for sharing! I wasn't aware of this until recently, it must've missed my radar. I'm fairly familiar with path tracer codebases (OpenMoonray/Cycles) and have done some hobby-level RHI work here and there, and this project combines them all in a very good way (and I see Google Marl there too, nice).

Just a few thoughts and questions from me trying to understand everything:

1. I am curious on how you'll solve mesh motion blur for the DXR 1.1 backend. As far as I know, only OptiX and Metal support this, and Vulkan partially via this extension https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_NV_ray_tracing_motion_blur.html (I want to make a ticket to Mesa3D to see if more hardware can support it...)

2. I noticed the use of argument buffers for Direct3D which is indirect cmd buffers on hardware right? - I think Vulkan is a bit behind there, but there is this extension https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_NV_device_generated_commands.html and on Linux the RADV driver supports a subset enough to cover Direct3D needs (I will test LuisaCompute under vkd3d-proton which uses it soon) - just a heads-up

3. Will the ISPC backend be resurrected? I found the last commit before its removal so I'll have a play with it with Embree - my assumption here is that data structures need to be in arrays in Mitsuba3-style like it is noted from the whitepaper for the benefits of the wider SIMDs (I am a bit confused as I thought LuisaCompute can abstract that with the DSL?).

4. How developed is the OSL parser? I'd like to use that to help lower OSL to GPUs or bring it to Moonray :)

5. This might be more of a LuisaRender question, but have there been any testing on making shader nodes in DSOs/modular libraries? I guess you'd embed the DSL in the libraries and invoke the JIT at runtime and be quite slow for time to first pixel waiting for compiles - that's something I'd like to study more, as Cycles has a VM to mitigate shader compiles but it's probably why it is slow in the render tests.

Cheers, and thanks for sharing this.

[Mike-Leo-Smith]

Hi, @boberfly,

Thank you for your interest in the project! Here are the answers to your questions:

1. Motion blur support is still a work in progress for CUDA and Metal. After that, we may leave it unsupported for DirectX or attempt to implement a software fallback.
2. Thanks for the information! We'll soon be working on the Vulkan backend (again!), and this info should help a lot. Testing Luisa under Proton is also very appreciated! This might be the simplest way to support Vulkan devices on Linux, or at least serve as a fallback while we transition to the true Vulkan backend.
3. I don't think we'll bring ISPC back in the short term. We had difficulty unlocking the full potential of ISPC and experienced slow compilation times. Also, since the CPU backend is now mostly for debugging and validation, we likely won't invest much work into it.
4. The OSL parser currently only parses OSO (the intermediate representation for compiled OSL shaders) into an internal form. The translation process is still under research, and we plan to eventually publish it as a technical paper.
5. Yes, the compilation of runtime-generated shaders can be quite slow, taking tens of seconds for complex scenes. Using SVMs like in Cycles can mitigate per-scene compilation at the cost of slower rendering, as we have to prepare registers for the most demanding code paths, even if they are not being used. We're researching a better way of translating shader graphs (as mentioned in Q4), and hopefully, we can find the right balance between compilation and rendering times.