GPUOpen-LibrariesAndSDKs / HIPRT

Other
97 stars 7 forks source link

HIPRT Optix wrapper? #6

Closed oscarbg closed 6 months ago

oscarbg commented 7 months ago

Hi,

don't know if it's asking too much from HIPRT project.. but curious, since HIP in concrete, is API wise almost a replica of CUDA API, so tools like HIPIFY allow converting CUDA source programs to HIP programs just asking if HIPRT devs plans on exposing a wrapper from Optix calls to HIPRT calls or even better change/augment HIPRT API set to expose APIs like Optix to not need big changes to existing Optix source codes to use HIP RT.. a recent example is AMD port of PBRT-v4 (which uses CUDA and Optix) to support AMD via HIP and HIPRT.. anounced here: https://gpuopen.com/learn/introducing-hip-rt-v2-2/ and seeing code: https://github.com/GPUOpen-Effects/pbrt-v4 the port was easy on the CUDA part (just HIPIFY the CUDA APIs): https://github.com/GPUOpen-Effects/pbrt-v4/commit/54bb210c2df841c89cb683c7bb7c4662d1c125fd but required new files (read complete rewrite) of Optix to HIPRT.. files like for example:src/pbrt/gpu/hiprt/aggregate.h

EDIT: thinking on not broad Optix API but a subset API used by almost any app like: https://github.com/nvpro-samples/optix_advanced_samples/tree/master/src/optixHello https://github.com/nvpro-samples/optix_advanced_samples/tree/master/src/optixGlass etc..

thanks..

meistdan commented 6 months ago

This is a good question. When we started designing HIPRT API, we could either mimic OptiX or design our own API. We decided for the latter option and thus these two APIs are quite different. OptiX implements the whole pipeline including shading, while HIPRT provides only the ray tracing functionality. In HIPRT, there are only 2 types of optional custom functions, which are much easier to setup than general STB in OptiX. Similarly, data assignment is explicit in HIPRT, making things transparent and easier to debug. A drawback is that there is no a simple script to convert an OptiX code to the HIPRT one.