Windows build fails with type inference errors in aov.cpp and gpt.cpp due to return type of camera->film()->node()->exposure(); about luisarender HOT 5 CLOSED

I had just updated everything before I built, it's called from within a Kernel2D though so it looks like it's not considering the host-side version, it's trying this one in compute/include/luisa/func.h instead.

Edit: So I already built with that change in place if that wasn't clear.

template<typename T>
    requires is_dsl_v<T> && is_floating_point_or_vector_expr_v<T>
[[nodiscard]] inline auto exp2(T &&x) noexcept {
    return detail::make_vector_call<float>(
        CallOp::EXP2, std::forward<T>(x));
}

I just noticed host side closure callables were added to that file 4 months ago though, which brings it back to being an issue with the return type of exposure() not being implicitly convertible to one of the compute namespaced types that satisfies the is_dsl_v and is_floating_point_or_vector_expr_v concepts, or maybe the type inference rules just not allowing it to look outside of the luisa:: namespace since assigning the luisa:float3 that was returned to a luisa:compute:dsl:Float3 instead of using auto didn't throw any warnings. I think there's an operator= assigned for the conversion but not an implicit ctor. Either this doesn't happen anywhere else or it was fixed already.

Anway I'll let you know if I find anything else. All of the integrators seemed to work fine (or as well as they're supposed to, I've never been able to get good results from pssmlt or megapm and megawave is extremely slow) until I tried to use the zsobol sampler with something and it created a call in the temp .cu file to a runtime function that didn't exist, which has been preventing luisa from generating anything else since so it just sends zero bytes and optix crashes. The directx backend still works so I'm not sure what's going on there. I'll have to try it again after I've run houdini or something else that reinitializes the driver cleanly.

from luisarender.

Hi @NeedsMoar

Thanks for reporting this issue!

We just added a host-side exp2(float3) in LuisaCompute (a submodule of LuisaRender) that didn’t exist before. So maybe the type mismatch was because the submodules in your clone are not updated?

Could you try

git submodule update --recursive --init

and see if it fixes the build?

from luisarender.

Thanks for the findings! I'll try to track down the type mismatches ASAP.

Anway I'll let you know if I find anything else. All of the integrators seemed to work fine (or as well as they're supposed to, I've never been able to get good results from pssmlt or megapm and megawave is extremely slow) until I tried to use the zsobol sampler with something and it created a call in the temp .cu file to a runtime function that didn't exist, which has been preventing luisa from generating anything else since so it just sends zero bytes and optix crashes. The directx backend still works so I'm not sure what's going on there. I'll have to try it again after I've run houdini or something else that reinitializes the driver cleanly.

This seems like another issue in the CUDA backend implementation. I'll look into it too.

from luisarender.

Hi @NeedsMoar

I believe the type mismatch issue is fixed now. For some reasons the compiler didn't select the correct overloading, so now I just explicitly specify the namespace as luisa::exp2 to ensure the overloading.

For the second integrator issue, mega-wave depends on thread-block sync functions that are unavailable with OptiX so it's expected to fail on the CUDA backend. I added an error message in the integrator to inform users.

from luisarender.

Sorry it took a bit. I wiped out my local changes and updated and everything built with no errors. Things seem to work ok fine so I'll go ahead and close this.

from luisarender.