Tending away from C API a mistake

We are evaluating Optix as a replacement for our multi-core raytracing engine and have notice a very disturbing tend in the software’s development. Staring with version 4.0, all of the C-API demos (samples1-6) have been removed from the distribution. Additionally, there are a number of errors in the documentation that make it unclear as to weather or not Optix is a C++ only API: a glaring example is on the front web page (https://developer.nvidia.com/optix) which lists

Key Features

Programmable GPU-accelerated Ray-Tracing Pipeline
Single-ray shader programming model using C++

I can tell you that C++ is a non-starter for us, and that the disturbing trend away from C support (e.g. not one single sample or demo in Optix 5.0 that demonstrates a pure C usage-case) makes potential adopters (us) very nervous about investing any more time or money into adapting to Optix if the development team is pushing for an API that emphases personal coding convenience/tastes and layers of dependencies over end-user flexibility and choice.

It seems clear that the original developers of Optix worked in C and I fear that a second-generation squad has seized control and started dismantling its foundations. Historically that indicates the founders have moved on and the project has entered into a slow decay and will eventually disappear (e.g. NVIDIA’s Gelato).

Can the Optix team reaffirm its support of the C API, and will it demonstrate that support by including a supported and maintained C-only demo in future release? Consider that the “flat-ness” and simplicity of the C language is also much more amenable to learning a new API and will lower the learning barrier to many new users.

If the answer to the above question is “no”, we will most-definitely pursue developing our own CUDA C ray-racing solution.

Thank you.

Case and Point:

On page 29 of the new (5.0.1) Programming Guide, section 3.5.3, the table entry description for “vertex_buffer_stride” makes mentions of “TriangleKdTree” and “Sbvh”, neither of which are listed under the “Available” column—the former (Kd Tree) has also been removed from the list of supported acceleration structures. Again, I had to go back to the (much more polished) 3.9.2 documentation to see that this method existed but has been dropped. In our experience on the GPU, Kd-Tree’s were the fastest acceleration method for path-tracing, but slow to build unless parallel-ized. We are assured (again back in the 3.9.2 documentation) that TriangleKdTree “…is rarely comparable to the SBVH in ray tracing performance”. While certainly possible, I find it disturbing again that we (the end-user) are no longer able to confirm this for ourselves, and the current Optix development team has decided “what is best” and removed our ability to experiment and draw our own conclusions. This is much like the post-4.0 team’s decision to shove C++ upon the developer, and again, a disturbing trend.

OptiX is using a C API. There is no intention to change that.

The C++ wrapper is implemented in the header optixpp_namespace.h shipped with the OptiX SDK and you can look at the actual C API calls it does. It’s there for convenience only.

Acceleration structures are continually improved and the API is evolving over time.

Glad to hear it.

Please pass along the feedback-back to your development team that the 5.0 SDK—as it currently exists—is longer friendly to a C developer, and the documentation has grown a bit ambiguous regarding the future of the C API support. For some, this is not a trivial matter, and unwrapping the C++ to a point in which a simple demo could be compiled proved to be a tedious and time-consuming task. Using the 3.9.2 samples with 5.0.1 libraries and headers directly also resulted in some rendering artifacts which are difficult to track down—especially when navigating unfamiliar territory.

As is the case with nearly all of the fundamental cross-platform API’s with real longevity, C++ should remain an optional wrapper and not become primary (as it already has in the 5.0 SDK tutorials) or required (which you have assured me it will not). While I am acting here as the bearer of the message, I assure you I am not alone in this thinking.

Thank you for your time and reply.

I agree, it would be valuable to have some “C-only” tutorials!

Thanks for the feedback.

The OptiX examples had been cleaned up and streamlined from previous versions. If there is a need for C API examples, we can add some again either in the SDK examples or maybe port one of the OptiX Advanced Samples on github. (Link in the sticky post on this sub-forum. There will be some more added soon after GTC 2018.)

OptiX is using a single-ray programming model, and that part is happening inside the device code which you control via CUDA code and that’s where you even have a lot of C++ functionality available, so it’s more of a “you’re not limited to C in the device code” what that sentence intended to express.

The OptiX Programming Guide is showing both the C API and example code using the C++ wrappers. A lot of work has been invested to make the OptiX Programming Guide more extensive and to be able to make that available online easier.

The OptiX API Reference is documenting the whole C API as well as the C++ wrappers and most of it is generated from the documentation inside the headers themselves.

The hub for all the online documentation is here: http://raytracing-docs.nvidia.com/optix/index.html

That would be great. Thank you!

Detlef,

Everything you say is correct, however my feedback still stands:

  1. The Programming manual has become slightly garbled and frequently errors on the side of only mentioning the C++ API. While the intent may seem clear to the developers, it is confusing to outsiders. This confusion is exacerbated by the lack of C API examples.

  2. The need for quarantined C API samples that are part of the SDK (and well maintained with regression testing) is real and would go a long way towards clarifying the Optix dependencies. The Programming Guide and/or the Quick Start Guide should then make direct reference to these examples when describing the C API.

The goal is, I assume, mass adoption. Clear communication is essential for that to happen.

Thank you again.